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Executive  Summary 


The  purpose  of  this  project  was  to  provide  systems  engineering  support  to  the  Force  XXI 
design  and  integration  efforts  of  the  Battle  Labs  Integration  and  Technology  Directorate, 
Deputy  Chief  of  Staff  for  Combat  Developments  (BLIT-CD)  and  the  Future  Doctrine 
Directorate,  Deputy  Chief  of  Staff  for  Doctrine  (FUTURE-DOC)  at  Training  and 
Doctrine  Command  Headquarters.  We  display  the  six  major  objectives  for  this  work  in 
shaded  boxes  along  with  the  major  findings  and  recommendations  summarized  below  each 
objective  in  clear  text  boxes. 


To  scope  and  bound  Force  XXI  design  efforts. 


To  scope  the  Force  XXI  design  effort,  we  identified  the  needs,  objectives,  and  criteria  of 
Force  XXI  from  a  systems  viewpoint.  Effective  needs  are  critical  because  the  definition 
of  a  successful  design  effort  is  meeting  or  exceeding  the  effective  needs  of  the  client  or 
stakeholder  group  in  a  cost-effective,  high-quality  way.  So  the  effective  needs  must 
answer  the  question,  “Why  are  we  redesigning  the  Army  to  Force  XXI?”  Five  statements 
drawn  with  some  modification  from  TRADOC  Pamphlet  525-5,  in  our  opinion,  answer 
this  question.  They  are: 

1.  To  be  trained  and  ready  to  win  the  first  land  battle  with  fewer,  more  economical 
but  more  capable  forces. 

2.  To  be  rapidly  tailorable,  rapidly  expansible,  strategically  deployable,  and 
effectively  employable  as  part  of  a  joint  and  multinational  team  to  achieve 
decisive  results  in  future  war  and  other  operations  in  all  environments. 

3.  To  win  simultaneous  operations  against  foes  of  varying  capabilities. 

4.  To  find  innovative  ways  to  apply  and  combine  current  and  new  technologies, 
especially  information  technologies,  for  warfighting. 

5.  To  win  tactical  battles  quickly  and  decisively  by  maximizing  information  and 
combat  power  to  dominate  the  battlespace. 


RECOMMENDATION  1:  That  the  effective  needs  of  the  Force  XXI 
design  effort  be  clearly  communicated  to  the  Army  to  unite  design  efforts 
across  organizations  toward  a  common  top-level  goal.  We  propose  the 
effective  needs  oudined  above  as  a  draft  for  senior  decision  makers  to 
sharpen  or  revise. _ 


To  make  Force  XXI  a  reality,  there  are  many  lower  level  goals  or  objectives  that  should 
be  pursued  in  a  coordinated  fashion  to  meet  or  exceed  the  effective  needs  of  Force  XXI. 
By  parsing  TRADOC  Pamphlet  525-5,  we  identified  more  than  seventy-five  (75) 
objectives  that  Battle  Labs  and  other  Army  organizations  may  want  to  pursue.  We 
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structured  these  objectives  into  a  conflict  matrix  of  six  objective  trees  or  hierarchies  to 
reflect  tactical,  operational,  and  strategic  concerns  across  war  and  operations  other  than 
war.  These  objectives  trees  represent  everything  that  the  Army  must  make  significant 
progress  on  to  make  Force  XXI  operations  a  reality. 


RECOMMENDATION  2:  That  Battle  Labs  and  other  Army 
organizations  identify  objectives  and  structure  their  objectives  into 
objective  trees,  similar  to  the  ones  contained  in  this  report,  so  they  can 
have  a  coherent  picture  of  everything  they  intend  to  accomplish  to  make 
significant  progress  toward  Force  XXI. _ 


One  of  the  findings  from  the  Battle  Lab  visits  was  that  they  had  difficulty 
articulating  their  objectives  and  understanding  the  objectives  that  they  shared  with  other 
organizations.  It  is  hard  to  make  progress  toward  a  goal  when  you  don’t  know  where  you 
are  going.  Note  that  this  does  not  conflict  with  the  idea  of  a  “journey  not  a  destination.” 
The  kind  of  objectives  that  are  outlined  in  this  report  are  statements  of  intent  that  allow 
for  many  different  alternatives  and  do  not  identify  specific  programs,  systems,  or 
technologies.  Again,  the  objectives  in  this  report  are  draft  objectives,  mostly  extracted 
from  TRADOC  Pamphlet  525-5  and  should  be  considered  as  illustrative  examples.  For 
the  objectives  to  be  worthwhile,  each  Battle  Lab  should  create  their  own  set  of  Force  XXI 
objectives  and  then  their  should  be  a  master  integration  effort  of  the  objectives  across  the 
Battle  Labs.  The  final  structure  of  objectives  should  be  integrated  into  subsequent 
revisions  of  Army  doctrine  so  that  organizations  can  pull  together  to  accomplish  them. 


RECOMMENDATION  3:  That  each  Battle  Lab  develop  meaningful, 
measurable  criteria  for  their  objectives.  In  this  way,  Battle  Labs  can 
determine  how  much  progress  they  are  making  towards  achieving  their 
objectives. _ 


The  objectives  trees  will  help  Battle  labs  develop  meaningful  measures  that  they  can  use  in 
experiments.  Although  higher  level  objectives  may  be  difficult  to  measure,  it  should  be 
possible  to  develop  measurable  criteria  for  each  lower  level  objective.  A  weighted 
combination  of  lower  level  criteria  can  be  used  to  measure  a  higher  level  objective. 


RECOMMENDATION  4:  That  Battle  Labs  should  construct  anti¬ 
objective  trees  which  show  objectives  that  counter  the  enemy’s  objectives. 
A  sample  anti-tree  is  in  the  report. _ 


To  bound  a  design  means  to  identify  the  constraints,  parameters,  and  variables  of 
the  problem.  Constraints  are  the  limits  that  are  placed  on  the  design  solution  and  help  to 
focus  the  design  efforts  toward  feasible  options.  Parameters  are  elements  of  the  design 
which  can  be  changed  to  help  define  competing  alternatives  but  they  do  not  change  once  a 
particular  alternative  is  in  operation.  For  example,  the  number  of  tanks  in  a  tank  company 
or  the  number  of  soldiers  in  any  infantry  squad  are  design  parameters  of  a  force  that  can 
be  changed  to  define  different  force  options.  Variables  are  important  quantities  that  we 
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want  to  monitor  as  the  design  alternative  actually  operates  or  is  simulated.  For  example, 
we  want  to  know  the  cost  of  various  force  design  options  in  terms  of  friendly  casualties 
suffered  in  likely  conflict  scenarios.  To  make  meaningful  design  progress,  we  need  to 
know  what  can  and  what  cannot  be  changed  and  how  important  variables  are  affected  by 
different  design  choices.  Here  are  some  sample  design  constraints,  parameters,  and 
variables  for  Force  XXI,  some  of  which  we  extracted  from  TRADOC  Pamphlet  525-5: 

Constraints  (Things  we  must  adhere  to  as  we  design  force  options.) 

•  Keep  a  division  base 

•  Maintain  soldier  focus 

•  Full  dimensional  force 

•  Change  leader-to-led  ratio 

•  Modular  combat  support  and  combat  service  support 

•  Smaller  staffs 

•  Smaller  units 

•  Mobile,  multi-functional  command  posts 

•  Incorporate  cybernetic  or  feedback  mechanisms  for  adaptation  and  innovation 

•  And  more 

Parameters  (Things  we  can  change  to  create  different  options.) 

•  Number  of  command  echelons  in  a  division 

•  Number  of  control  elements  at  each  command  echelon  (e.g.,  tactical  command  posts) 

•  Number  of  staff  elements  at  each  command  echelon 

•  Type  of  staff  elements  at  each  echelon 

•  Number  of  staff  personnel  in  each  element 

•  Number  of  units  in  each  echelon  of  command 

•  Type  of  units  in  each  echelon 

•  Number  of  systems  (e.g.,  tank,  Infantry  Fighting  Vehicle)  in  each  unit 

•  Type  of  systems  in  each  unit 

•  Number  of  soldiers  in  each  crew  or  squad 

•  Type  of  soldiers  in  each  crew  or  squad 

•  Type  of  units  in  the  division  base 

•  Size  of  units  in  the  division  base 

•  Number  of  functions  performed  at  each  echelon,  unit,  or  element 

•  Type  of  function  performed  at  each  echelon,  unit,  or  element. 

•  And  more  (such  as  Doctrine,  Training,  Leaders,  Organization,  Materiel,  Soldiers) 

Variables  (Things  we  must  monitor  when  we  exercise  or  simulate  force  options) 

•  Amount  of  battlespace  that  can  be  dominated  or  controlled  by  the  force 

•  Force  recognition  time  (time  that  it  takes  for  the  force  to  recognize  significant 
battlefield  situations) 

•  Force  response  time  (time  that  it  takes  for  the  force  to  respond  to  significant  battlefield 
situations  once  recognition  has  occurred) 


•  Force  tempo  (the  number  of  significant  battlefield  situations  that  the  force  can 
recognize  and  respond  to  in  some  specified  unit  of  time) 

•  Number  of  enemy  systems  killed 

•  Number  of  friendly  casualties 

•  Consumption  rates  (ammunition,  fuel,  food,  expendable  supplies) 

•  And  many  more 

In  addition  to  internal  thinking  about  how  the  Army  can  change  itself,  we  need  some  “out 
of  the  box”  thinking  about  how  the  other  services,  that  are  part  of  the  joint  team,  could 
change  to  make  the  overall  team  more  efficient  and  effective.  For  example,  are  there 
functions  or  activities  that  take  up  a  significant  part  of  the  Army’s  budget  that  should  be 
offloaded  to  another  service  or  are  their  better  ways  that  other  services  could  accomplish 
their  functions  and  activities  that  would  generate  a  savings  that  could  be  put  to  good  use 
by  the  Army.  Perhaps  there  are  functions  and  activities  that  the  Army  performs  for  other 
agencies  that  should  be  done  on  a  reimbursable  basis.  The  systems  point  of  view  calls  for 
examining  not  just  redesigning  the  Army  put  also  understanding  how  the  Army  should  fit 
and  work  with  all  the  other  systems  in  its  operating  environment. 
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To  help  understand  past  Army  Warfighting  Experiments  (AWEs),  Advanced 
Technology  Demonstrations  (ATDs),  and  real  operations  in  terms  of  their  impact  on 


RECOMMENDATION  8:  That  the  results  of  Army  Warfighting 
Experiments  (AWEs)  be  crosswalked  with  the  main  ideas  in  TRADOC 
Pamphlet  525-5  to  identify  trends  that  confirm  or  refute  doctrinal  ideas  and 
to  identify  knowledge  gaps  where  we  need  additional  experimentation.  A 
sample  method  to  accomplish  this  with  a  crosswalk  and  results  matrix  is  in 
the  report. _ 


RECOMMENDATION  9:  That  Battle  Labs  analyze  recent  real 
operations  to  understand  shortcomings  associated  with  their  areas  of 
oversight.  A  sample  analysis  of  a  recent  operation  is  in  the  report.  To 
accomplish  this,  the  Battle  Labs  will  need  access  to  information  about  these 
operations,  including  perhaps  real-time  observers  and  qualified  military 
operations  analysts. _ 


To  help  improveBatfle  Lafrprocesses. 


RECOMMENDATION  10:  That  Battle  Labs  develop  a  more  detailed 
understanding  of  the  battlefield  activities  they  are  trying  to  improve  by 
constructing  activity  models  (IDEFO)  of  their  battlefield  activities.  A 
sample  battlefield  activity  model  for  leading  infantry  battle  complete  with 
node  trees  and  decomposition  diagrams  is  in  the  report. _ 


This  does  not  imply  that  Battle  Labs  do  not  understand  their  battlefield  activities.  Rather, 
it  means  that  the  Battle  Labs  have  difficulty  explaining  these  activities  to  others  and  in 
communicating  their  reasons  and  justifying  the  value-added  of  particular  technologies  or 
other  changes  they  want  to  make  to  the  way  they  accomplish  their  battlefield  activities. 


RECOMMENDATION  11:  That  Battle  Labs  adopt  and  use  a  systemic, 
life-cycle  process  for  the  identification,  assessment,  and  preliminary 
implementation  of  technology.  This  life-cycle  has  seven  (7)  important  and 
related  steps:  Scouting,  Documentation,  Assessment,  Selection, 
Tracking,  Disengaging,  and  Supporting.  More  details  on  how  this 
process  works  is  in  the  report.  To  accomplish  this,  the  Battle  Labs  will 
need  “Technology  Scouts”  out  immersed  in  the  commercial  sector  who 
know  the  Army  and  can  understand  technology  and  its  potential 
applications  to  warfighting. _ 


RECOMMENDATION  12:  That  the  Battle  Labs  develop  a  better 
understanding  of  battlefield  and  system  architecture.  This  includes  not  just 
the  physical  and  functional  architecture  but  also  the  operational 
architecture  for  their  area  of  concern—  how  does  it  work  when  it  is 
actually  put  into  operation  and  where  are  the  problems  that  arise  during 
different  modes  of  operation. _ 


The  recommendations  from  this  work,  if  put  into  action,  should  help  support  the  Battle 
Labs  and  other  Army  organizations  and  offices  to  make  and  evaluate  progress  on  Force 
XXI.  We  shared  interim  briefings  and  emerging  results  from  this  effort  with  COLs 
Hubbard  and  Klevecz,  and  Ms  Schuetze  (BLIT-CD),  MG  Boyd  and  COL  Starry 
(DCSDOC),  and  Dr.  Phil  Dickinson,  Chair,  Battle  Labs  Issues  Study  Group,  Army 
Science  Board. 
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1.0  Project  Objectives 

We  were  tasked  with  the  following  six  major  objectives  for  this  effort: 

•  To  scope  and  bound  Force  XXI  design  efforts. 

•  To  help  establish  a  coherent  framework  and  consistent  terminology  for 
Force  XXI. 

•  To  help  understand  past  Army  Warfighting  Experiments  (AWEs)  and 
Advanced  Technology  Demonstrations  (ATDs),  and  real  operations  in  terms 
of  their  impact  on  designing  Force  XXI  from  a  holistic  perspective. 

•  To  help  guide  future  AWEs  and  ATDs. 

•  To  help  improve  the  Battle  Labs  processes. 

•  To  help  organize  knowledge  for  Force  XXI  decision  makers. 

Achieving  these  goals  will  aid  in  moving  from  the  current  Army  to  the  desired  end 

state,  meeting  the  effective  needs  of  Force  XXI.  The  clients  for  this  effort  are  the  Battle 
Lab  Integration  and  Technology  (BLIT)  Office  and  the  Future  Doctrine  Office  at  the  US 
Army  Training  and  Doctrine  Command  (TRADOC)  Headquarters,  Ft.  Monroe,  Virginia. 
The  results  of  this  work  should  support  their  efforts  in  helping  the  Battle  Labs  to  make 
and  evaluate  their  progress  on  Force  XXI. 

Effective  Needs  of  the  Army 
•To  be  trained  and  ready  to  win  the  land  battle 
•To  have  fewer,  but  more  economical  forces 
•To  have  the  same  or  greater  capability 
•To  leverage  current  and  new  technologies 

_ - - - - - _ - - - - 


Figure  1.1  Designing  Force  XXI 
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2.0  Scoping  Force  XXI 

To  scope  the  Force  XXI  design  effort,  we  identified  the  needs,  objectives,  and 
criteria  of  Force  XXI  as  a  system.  Needs  are  conditions  requiring  relief  or  are  the  lack  of 
something  required,  desired,  or  useful.1  Satisfying  the  effective  needs  of  a  client  or 
stakeholder  group  in  a  cost-effective,  high-quality  way  is  the  definition  of  a  successful 
systems  engineering  design  effort.  Effective  needs,  as  opposed  to  primitive  needs,  are 
needs  that  have  been  analyzed  and  supported  with  evidence  and  convincing  rationale.  The 
effective  needs  for  Force  XXI,  listed  in  the  box  below,  were  extracted  from  TRADOC 
Pamphlet  525-5,  Force  XXI  Operations. 


•  To  be  trained  and  ready  to  win  the  first  land  battle  with  fewer,  more  economical 
but  more  capable  forces. 

•  To  be  rapidly  tailorable,  rapidly  expansible,  strategically  deployable,  and  effectively 
employable  as  part  of  a  joint  and  multinational  team  to  achieve  decisive  results  in 
future  war  and  operations  other  than  war  (OOTW)  in  all  operational  environments 

•  To  win  simultaneous  operations  against  foes  of  varying  capabilities. 

•  To  find  innovative  ways  to  apply  and  combine  current  and  new  technologies, 
especially  information  technologies,  for  warfighting. 

•  To  win  tactical  battles  quickly  and  decisively  by  maximizing  information  and 
combat  power  to  dominate  the  battlespace. 


1  Webster’s  Ninth  New  Collegiate  Dictionary,  1990. 
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Effective  needs  are  usually  broad,  top  level  goals  that  must  be  accomplished  for 
the  effort  to  be  a  success.  Therefore,  to  get  started  on  meaningful  design  work,  it  is 
typically  necessary  to  define  a  set  of  lower  level  goals  or  objectives,  that  when  completed, 
will  satisfy  the  effective  needs. 

Before  describing  how  we  built  the  objectives  trees,  let  us  describe  what  they  are 
and  why  they  are  useful.  Objective  trees  are  hierarchical  structures  that  display  the 
objectives  of  a  design  project  from  the  top  down.  The  reasons  for  using  objectives  trees 
to  guide  a  design  effort  are  listed  in  the  bullets  below. 

•  They  represent  everything  the  stakeholders  want  to  accomplish  with  the  design 
effort. 

•  They  help  to  guide  the  development  of  criteria  which  can  then  be  used  to  evaluate 
and  compare  alternative  designs. 

•  They  help  to  spark  the  ideation  of  activities  which  can  then  be  used  to  generate 
alternatives. 

•  They  help  to  identify  trade-offs  that  must  be  carefully  considered. 

•  They  reveal  hidden  agendas  and  priorities  of  important  stakeholders. 

•  They  rationalize  means  to  ends. 

Although  analyzing  needs  and  constructing  objectives  are  best  accomplished  with 
the  willing  participation  of  the  stakeholders  (Battle  Labs),  we  did  this  work  to  illustrate 
what  can  be  done  and  why  it  is  useful  to  a  large  scale  design  effort.  As  part  of  this 
project,  LTC  Armstrong  was  an  adjunct  member  of  the  Army  Science  Board  Battle  Labs 
Issues  Study  Group  and  was  able  to  visit  several  of  the  labs  as  part  of  that  group.  To 
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construct  the  objectives  trees  found  in  Appendix  A,  B,  and  C,  we  first  parsed  TRADOC 
Pamphlet  525-5  and  extracted  a  list  of  objectives  from  the  document.  We  found  most  of 
the  objectives  we  used  in  Chapter  3  of  525-5.  The  objectives  did  not  seem  to  tie  together 
very  well  until  we  divided  them  into  their  respective  levels  of  warfare:  strategic, 
operational,  and  tactical.  Although  525-5  talks  about  how  these  levels  of  war  are  going  to 
be  compressed  in  time  and  space,  we  found  it  useful  as  an  organizing  principle  to 
segregate  objectives  into  these  three  time-compressed  but  interrelated  categories.  We  also 
found  it  necessary  to  divide  these  three  levels  of  goals  into  two  categories:  war  and 
operations  other  than  war  (OOTW).  We  then  constructed  a  tree  for  each  level  on  each 
side  for  a  total  of  six  trees.  This  partition  of  objectives  formed  the  conflict  matrix  shown  in 
Table  2.1.  See  Appendices  A  and  B  for  the  objectives  trees. 

Each  objective  tree  represents  what  525-5  says  the  Army  needs  to  accomplish  for 
Force  XXI  operations.  We  think  it  would  be  a  very  useful  exercise  for  the  Battle  Labs  to 
layout  a  similar  set  of  objectives  trees  and  indicate  which  objectives  they  are  working  on 
and  which  objectives  they  share  with  other  labs. 


Table  2.1  Conflict  Matrix 


WAR 

OOTW 

Strategic 

X 

X 

Operational 

X 

X 

Tactical 

X 

X 

X=  One  Objectives  Tree 


We  note  that  any  specific  conflict  will  probably  involve  several  if  not  all  of  these 
entries  in  the  matrix.  It  will  be  necessary  to  transition  from  one  to  another  and  we  will 
probably  be  involved  in  conflict  at  multiple  levels  simultaneously.  For  example,  if  we  are 
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successful  against  the  enemy  in  a  tactical  war  operation,  it  may  be  necessary  to  conduct 
peacekeeping  operations  (OOTW). 

Once  Battle  Labs  identify  the  objectives  that  they  are  working  on,  then  they  could 
explain  what  criteria  they  are  using  to  measure  their  success  in  achieving  their  set  of 
objectives.  They  could  also  explain  how  planned  warfighting  experiments  and  simulations 
relate  to  their  objectives  and  what  measurements  will  be  taken  during  these  events  that  will 
relate  to  the  criteria  they  are  using  to  measure  their  objectives. 

Additionally,  we  looked  at  the  idea  of  developing  what  we  have  termed  “anti¬ 
trees”  since  war  is  a  two-sided  contest:  friendly  and  enemy.  For  all  six  trees  we 
developed,  there  are  anti-trees  that  contain  objectives  which  apply  to  countering  the 
enemy.  For  every  objective  we  are  trying  to  accomplish,  the  enemy  is  trying  to 
accomplish  a  similar  objective.  Therefore,  we  should  develop  specific  objectives  for 
hindering  the  enemy’s  ability  to  accomplish  these  objectives.  For  example,  some  of  our 
trees  contain  the  objective  “To  gain  and  share  accurate  and  timely  information.”  An  anti¬ 
tree  which  applies  to  taking  action  against  the  enemy  might  have  the  objective  “To  hinder 
or  disrupt  the  enemy’s  ability  to  gain  and  share  accurate  and  timely  information.”  This 
would  allow  Force  XXI  decision  makers  to  look  at  both  sides  of  war  and  OOTW  and 
allocate  resources  appropriately.  Although  we  developed  only  one  anti-tree,  anti-tactical 
war  as  shown  in  Appendix  C,  we  think  it  would  be  useful  to  develop  an  anti-tree  for  each 
‘X’  in  the  Conflict  Matrix. 

One  of  the  important  payoffs  from  objectives  trees  is  that  they  help  you  develop 
criteria.  Criteria  measure  success  in  attaining  objectives  and  are  very  useful  for  evaluating 
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alternative  designs.  For  example,  in  any  experiments  investigating  Force  XXI  initiatives, 
you  would  expect  to  see  data  collection  efforts  oriented  on  quantifiable  criteria  that 
measure  specific  objectives.  The  idea  is  to  use  lower  level  objectives  to  help  suggest 
criteria  or  objectives  measures.  As  an  example  of  this,  we  defined  the  criteria  (with  units 
in  parentheses),  shown  in  Table  2.2,  as  possible  ways  to  measure  some  of  the  Force  XXI 
objectives. 


Table  2.2  Possible  Force  XXI  Success  Criteria 


Objective a 

'i Criteria  (with  Units)  III! 

To  maximize  the  warning  time  for 
commitments 

Warning  time  (in  Days) 

To  maximize  the  number  of  simultaneous 
operations  controlled  at  each  level 

Number  of  simultaneous  operations 
(number) 

To  maximize  the  number  of  nearly 
simultaneous  attacks  throughout  the 
battlespace 

Number  of  nearly  simultaneous  attacks  in 
one  hour  (number) 

To  maximize  stand-off  ranges  for  major 
weapons  systems 

Percent  increase  in  stand-off  range  (%) 
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3.0  Bounding  Force  XXI 

To  bound  Force  XXI,  we  identified  the  parameters,  variables,  and  constraints  of 
the  system.  Parameters  are  characteristics  which  do  not  change  once  the  system  is  in 
operation.  Examples  of  parameters  are  the  number  and  type  of  units  in  place  once  Force 
XXI  is  implemented  and  the  command  and  control  structure  for  these  units.  Once  Fore 
XXI  is  put  into  place,  these  parameters  are  not  likely  to  change  much.  In  fact,  the  values 
to  which  these  parameters  are  set  will  largely  define  the  various  alternative  designs  for 
Force  XXI  and  determine  the  relative  capabilities  that  each  design  can  achieve. 

A  variable  is  something  that  changes  as  the  system  (Force  XXI)  operates.  There 
are  many  variables  that  change  as  a  force  operates:  ammunition  on  hand,  soldiers  present 
for  duty,  and  the  number  of  operational  combat  vehicles  are  a  few  examples. 
Understanding  how  these  variables  are  likely  to  change  due  to  different  Force  XXI  designs 
is  important  especially  when  considering  force  employment  and  sustainment  issues. 
TRADOC  Pamphlet  525-5  addresses  some  of  these  issues  but  without  much  resolution  or 
definitions  of  success. 

Constraints  are  the  boundary  conditions  within  which  the  system  must  operate. 
Although  some  of  these  constraints  may  not  be  binding,  which  means  that  Army  leaders 
may  decide  some  may  have  to  be  violated,  we  have  identified  some  important  Force  XXI 
constraints  from  525-5  that  will  impact  the  design  of  the  Army  for  the  21st  century: 

•  Keep  a  Division  Base 

•  Maintain  Soldier  Focus 


•  Full  Dimensional  Force 


Must  Change  Leader-to-Led  Ratio 

Modular  Combat  Support  (CS)  and  Combat  Service  Support  (CSS) 
Smaller  Staffs 

Mobile,  Multi-Functional  Command  Posts 


Incorporate  Cybernetic  or  Feedback  Mechanisms 
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4.0  Terminology  and  Paradigms 

Since  doctrine  provides  a  common  language  as  a  basis  for  communication  and 
understanding,  we  think  it  is  important  to  help  establish  a  consistent  terminology  and 
common  understanding  for  Force  XXI. 

4.1  Force  XXI  Terms 

To  this  end,  we  looked  at  the  glossary  and  text  of  525-5.  We  attempted  to  define  any 
terms  that  we  did  not  find  in  the  glossary.  We  found  that  there  are  many  different  terms 
used  that  are  not  well  defined  or  widely  understood  although  they  may  be  well  understood 
by  key  decision  makers.  In  fairness  to  the  writers  of  525-5,  their  aim  was  to  think  into  the 
future,  so  you  would  expect  terms  and  concepts  that  are  still  emerging  and  are  not  well- 
defined  to  be  integral  to  the  document’s  purpose.  It  is  essential  that  doctrine  has  a 
consistent  terminology  so  that  a  common  language  exists  for  understanding  and  discussing 
concepts  of  operation,  tactics,  techniques,  and  procedures.  Therefore,  more  work  needs 
to  be  done  to  carefully  define  Force  XXI  terms,  explain  what  they  mean,  and  explain  how 
they  relate  to  each  other  in  the  context  of  Force  XXI  operations.  The  table  below  is  a  list 
of  some  key  terms  with  possible  definitions. 

Table  4.1  Sample  Force  XXI  Terms  and  Definitions 


battle 

Combat  between  armed  forces 

LTC  Armstrong 

dynamic 

Cause  of  change  over  time  in  a  system, 
process,  or  operation 

LTC  Armstrong 

battle  dynamic 

A  cause  of  change  over  time  in  combat 
between  armed  forces.  In  525-5,  a  significant 
area  of  change  from  current  operations  to 
Force  XXI  operations.  Five  major 
interrelated  battle  dynamics  are  battle 
command,  battlespace,  depth  and 
simultaneous  attack,  early  entry,  and  combat 
service  support. 

Modified  FM  525-5 

space 

The  infinite  dimension  of  the  three 
dimensional  field. 

Webster 

battlespace 

The  depth,  breadth,  and  height  within  which 
the  conflict  or  combat  between  armed  forces 
occurs.  The  dimensions  of  battlespace  are 
determined  by  the  maximum  capabilities  of 
friendly  and  enemy  forces  to  acquire  and 
dominate  each  other  by  fires,  maneuver,  and 
information. 

Modified  525-5 

commitments 

Engagements  to  which  US  military  forces  will 
be  bound  to  accomplish  missions  in  both  war 
and  OOTW. 

Modified  525-5 

connectivity 

The  quality  or  state  of  being  joined  or  linked 
together  with  other  force  elements  so  that  the 
elements  can  exchange  information  and 
coordinate  their  operations.  Often  used  in 
the  context  of  having  the  ability  to  coordinate 
and  perform  joint,  interagency,  or 
multinational  operations  via  communications 
links. 

LTC  Armstrong 

expansible 

Capable  of  being  increased  in  number, 
volume,  scope,  or  extent  especially  the 
battlespace  that  the  force  occupies  and 
dominates  after  expansion. 

Modified  Webster 

interchangeable 

The  ability  to  substitute  each  (of  two)  force 
elements  or  components  for  each  other. 

Modified  Webster 

tailorable 

The  ability  to  adapt,  change,  or  organize 
force  elements  to  suit  a  special  need  or 
purpose  such  as  a  particular  situation  defined 
by  the  mission,  enemy,  terrain,  troops,  and 
time  available  (METT-T). 

LTC  Armstrong 

modularity 

A  force  design  methodology  that  establishes  a 
means  to  provide  interchangeable, 
expandable,  and  tailorable  force  elements. 

525-5 

operation 

A  set  of  synchronized  actions  planned  and 
executed  to  achieve  an  objective. 

LTC  Armstrong 

information 

Communication  or  reception  of  knowledge 
that  increases  the  ability  to  understand  and 
deal  with  current  and  future  situations, 
especially  new  or  difficult  situations. 

LTC  Armstrong 

information 

operation 

A  set  of  synchronized  information  actions 
planned  and  executed  to  achieve  or  help 
achieve  an  objective.  In  525-5,  continuous 
combined  arms  operations  that  enable, 

LTC  Armstrong  and 
525-5 
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enhance,  and  protect  the  commander’s 
decision  cycle  and  execution  while 
influencing  an  opponent’s;  operations  are 
accomplished  through  effective  intelligence, 
command  and  control,  and  command  and 
control  warfare  operations,  supported  by  all 
available  information  systems;  battle 
command  information  operations  are 
conducted  across  the  full  range  of  military 
operations. 

process 

A  series  of  interdependent  steps  that  result  in 
a  significant  change  to  some  object  or  set  of 
things. 

LTC  Armstrong 

system 

A  set  of  components  or  elements  that  work 
together  for  a  specific  purpose. 

LTC  Armstrong 

technology 

The  organization  and  application  of  scientific 
and  engineering  knowledge  to  enhance  some 
human  activity  (such  as  warfare)  or  to  extend 
some  natural  process  by  manmade  means. 

LTC  Armstrong 

technology  trend 

The  general  direction  that  the  enhancement  of 
some  human  activity  takes  over  time. 

LTC  Armstrong 

simultaneous 

Happening,  existing  or  done  at  the  same  time 
or  within  some  specified  timeframe. 

Adapted  from 

Webster 

tempo 

The  rate  or  pace  of  some  activity. 

Webster 

4.2  A  Force  XXI  Paradigm 

A  paradigm  is  an  outstandingly  clear  example  or  simple  model  that  helps  people 
understand  and  think  about  reality  better.  So,  as  we  write  doctrine  and  train  leaders  and 
soldiers,  we  need  to  ask  ourselves  what  is  the  clear  example  or  simple  model  that  leaders 
and  soldiers  are  using  in  their  minds  to  understand  and  think  about  Force  XXI  and  future 
conflict.  To  be  useful,  a  paradigm  must  help  us  understand  and  explain  reality.  It  must 
help  us  get  answers  to  important  questions  about  why  we  are  making  changes  to  the  way 
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the  force  is  designed  and  why  we  are  making  changes  to  the  way  we  operate  the  force. 

We  might  start  by  asking  what  is  the  old  paradigm  we  were  all  using  and  is  it  still 
appropriate  for  the  future? 

The  current  paradigm  is  the  relative  combat  power  model  developed  by  BG  (ret.) 
Huba  Wass  de  Czege.2  According  to  doctrine  experts,  it  has  served  as  the  basis  for  all 
versions  of  FM  100-5  since  1982.3  His  model  states  that  the  outcome  of  battle  depends 
on  the  difference  in  the  combat  power  of  the  antagonists.  Combat  power,  in  his  model,  is 
a  function  of  what  leaders  do  with  the  firepower,  maneuver,  and  protection  capabilities  of 
their  units.  He  stresses  the  word  “relative”  because  it  is  the  combat  power  effects  that  are 
generated  at  the  decisive  place  and  time  on  the  battlefield  that  count  not  just  the  potential 
for  combat  power  in  general.  This  means  that  you  can  fight  outnumbered  and  win  if  you 
are  smarter  than  your  enemy.  His  model  also  recognizes  that  warfare  is  a  two-sided 
contest  by  including  a  degradation  factor  to  combat  power  that  represents  one  side’s  effort 
to  minimize  the  other  side’s  combat  capabilities  and  vice  versa.  Is  this  model  good 
enough  or  do  we  need  to  update  it  for  the  information  age  Army?  If  so,  then  how? 

One  way  to  update  the  relative  combat  power  for  the  information  age  is  to  add 
information  as  another  main  variable  or  effect  to  the  model.  In  this  updated  model, 
combat  power  is  now  a  function  of  what  leaders  do  with  the  firepower,  maneuver, 
protection,  and  information  capabilities  of  their  units.  Of  course,  each  of  the  variables  in 
the  combat  power  model  is  a  function  of  many  other  important  variables.  BG  Wass  de 
Czege  does  an  excellent  job  of  detailing  all  of  these  complexities.  In  fact,  there  are  many 

2  Understanding  and  Developing  Combat  Power  by  Huba  Wass  de  Czege,  February  10, 1984. 

3  Memorandum  by  Colonel  Mike  Starry,  Subject:  Analytic  Foundations  for  the  “Long  View,”  September 
7, 1994. 
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information  variables  embedded  in  many  of  his  detailed  explanations  of  firepower, 
maneuver,  and  protection.  A  challenge  for  Force  XXI  is  to  organize  and  understand  the 
application  of  information  effects  as  a  way  of  generating  combat  power  to  the  same  level 
of  detail  as  the  other  terms  in  the  combat  power  model.  For  instance,  there  are  at  least 
two  more  levels  of  abstraction  or  layers  of  variables  in  the  original  model  (18  more 
specific  variables  at  the  second  level  and  64  at  the  third  or  lowest  level).  Here  is  a  the 
relative  combat  power  model  updated  for  information  showing  the  first  level  of  five  basic 
variables. 

Lf  (Ff  +  Mf+  Pf  +  If  -  De)  -  Le  (Fe  +  Me  +  Pe  +  Ie  -Df)  =  The  Outcome  of  Battle 

Figure  4. 1  Combat  Power  Model  Equation  Updated  for  the  Information  Age 

where 

Lf  -  friendly  leadership  effect  Le  -  enemy  leadership  effect 

Ff  -  friendly  firepower  effect  Fe  -  enemy  firepower  effect 

Mf  -  friendly  maneuver  effect  Me  -  enemy  maneuver  effect 

Pf  -  friendly  protection  effect  Pe  -  enemy  protection  effect 

If  -  friendly  information  effect  Ie  -  enemy  information  effect 

De  -  enemy  degrading  of  effects  Df  -  friendly  degrading  of  effects 
One  of  the  advantages  of  the  combat  power  model  was  that  it  included  both 
qualitative  and  quantitative  aspects.  That  is,  it  was  not  just  a  subjective  model  that 
claimed  warfare  was  only  an  art  nor  was  it  only  an  objective  model  that  claimed  warfare 
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was  just  a  science.  It  allowed  for  the  judicious  blend  of  both  perspectives.  Still,  we  might 
want  to  examine  one  more  aspect  of  the  combat  power  model  that  appears  to  limit  its 
application  in  the  information  age  even  after  adding  the  information  term.  This  limiting 
aspect  concerns  the  basic  assumptions  of  the  model.  What  were  these? 

As  you  might  expect,  the  original  combat  power  model  assumed  the  continued 
preeminent  concern  of  the  Soviet  Union.  Therefore,  the  central  purpose  of  the  combat 
power  model  was  to  turn  combat  potential  into  combat  power  in  such  a  way  as  to  defeat 
Soviet  forces  in  combat  action.  While  the  purpose  of  combat  action  is  still  of  great 
importance,  we  need  to  also  consider  the  other  possibilities  that  exist  in  the  information 
age.  For  example,  consider  the  diagram  in  Figure  7.2  below  which  shows  the  basic 
command  and  control  process  for  two  opposing  forces.4  The  traditional  combat  power 
model  focuses  on  the  primary  possibility  of  direct  combat  where  the  blue  forces  and  red 
forces  are  engaged  against  each  other  in  combat  actions.  This  traditional  possibility  is 
shown  in  the  diagram  as  the  double  headed  arrow  labeled  combat.  New  information  age 
technologies  now  make  the  other  possibilities  shown  by  the  psychological  operations 
arrow  and  the  information  operation  arrows  important  to  consider.  The  diagram  shows 
that  we  can  potentially  put  effects  now,  better  than  ever  perhaps,  on  the  goals,  decision 
processes,  and  the  sensor  or  information  gathering  capabilities  of  our  enemies.  The 
possibilities  become  even  more  interesting  when  you  examine  a  third  party  to  the  conflict 


4  Adapted  from  a  diagram  in  William  B.  Cunningham’s  briefing  “A  Proposed  Approach  to  Understanding 
and  Modeling  Information  Operations,”  January  12, 1996.  The  author,  J.  E.  Armstrong,  presented  similar 
ideas  in  the  context  of  command  and  control  systems  in  1987  in  a  technical  report  “Decision  Making 
Models  for  Command  and  Control.”  This  general  sense-decide-act  process,  or  observe-decide-act  cycle, 
has  been  called  the  command-and-control  process  model  by  Lawson  originally  and  then  also  the 
commander’s  decision  cycle,  so  perhaps  this  paradigm  is  not  new  but  also  needs  to  be  updated  for  the 
information  age. 
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such  as  a  peacekeeper  who  now  can  put  effects  on  both  antagonists  (as  well  as  receive 
effects  from  both).  A  complete  discussion  of  this  paradigm  for  thinking  about  conflict  is 
beyond  the  scope  of  this  report  but  it  does  illustrate  the  need  for  considering  the  kind  of 
thinking  or  analytical  framework  we  want  Army  leaders  to  use  to  understand  warfare  in 
the  21st  century. 


Figure  4.2  New  Paradigm  for  21st  Century  Conflict 


16 


5.0  Learning  from  Past  and  Future  AWEs 

To  help  understand  past  and  future  Army  Warfighting  Experiments  (AWEs),  we 
developed  a  crosswalk  of  525-5  main  ideas  and  Battle  Lab  experiments  (AWEs).  By 
rating  each  experiment  for  its  success  in  achieving  a 
main  idea,  analysts  will  be  able  to  identify  gaps  and 
trends  in  performance  for  senior  decision  makers. 

We  suggest  using  simple  entries  in  a  crosswalk  or  interaction  matrix  like  the  one 
shown  at  the  right.  An  entry  of  means  that  the  experiment’s  results  seemed  to 
contradict  the  main  idea  outlined  in  525-5.  An  entry  of  ‘0’  means  that  the  experiment’s 
results  did  not  seem  to  provide  any  information  to  either  confirm  or  contradict  the  main 
idea.  When  the  results  of  an  experiment  confirm  a  main  idea  described  in  525-5,  then  an 
entry  of  V  is  made.  Crosswalking  results  from  experiments  to  the  main  ideas  or  premises 
in  525-5  provides  a  way  to  better  understand  past  experiments  and  also  a  way  to  guide  the 
design  of  future  experiments. 

A  positive  trend,  evidenced  by  a  row  of  many  Vs,  indicates  that  the  main  idea  in 
525-5  appears  to  be  confirmed  by  several  warfighting  experiments.  A  gap,  evidenced  by  a 
row  of  many  ‘0’s,  means  that  the  main  idea  was  not  tested  by  the  experiment  and  that 
perhaps  the  idea  should  be  considered  for  future  experimentation.  A  negative  trend, 
evidenced  by  a  row  of  ‘-’s,  indicates  that  the  main  idea  may  not  be  a  great  idea;  the 
decision  makers  will  have  to  reexamine  the  idea.  The  table  below  shows  what  a  crosswalk 
of  525-5  main  ideas  and  AWEs  might  look  like.  Appendix  I  demonstrates  a  framework 


for  accomplishing  this  task  that  relates  individual  AWEs  with  their  corresponding 
hypotheses,  results,  and  insights  to  this  crosswalk  matrix. 
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Table  5.2  Sample  Crosswalk  Matrix  of  525-5  Main  Ideas  with  AWEs 
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Each  entry  in  the  crosswalk  or  interaction  matrix  above  has  to  be  supported  by  additional 
information.  We  recommend  a  supporting  table  like  the  one  shown  below  for  each  AWE 
that  list  the  hypotheses,  results  and  insights  for  each  experiment.  These  summaries  of 
AWE  results  should  be  put  together  by  an  analytical  agency  such  as  TRADOC  Analysis 
Command  in  coordination  with  the  appropriate  Battle  Lab. 

Table  5.3  Sample  Supporting  AWE  Information  Table  for  Crosswalk  Matrix 


Task  Force  XXI  &i2 

s  If.', .  MMi 

Then.,, 

Results  ' . 

Information-age 
battle  command 
capabilities  and 
connectivity  exists 
across  all  battlefield 
operating  systems 
and  functions  within 
and  to  a  brigade  task 
force. 

Significant 
enhancements  in 
lethality, 

survivability,  and 
tempo  will  be 
achieved. 

TBD 

TBD 
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6.0  Improving  Battle  Lab  Processes 

Previous  sections  in  this  report  discuss  how  Battle  labs  may  want  to  use  objectives 
trees  to  chart  their  course  and  measure  their  progress  and  how  they  can  crosswalk  results 
from  AWEs  with  future  doctrine  to  better  understand  past  experiments  and  to  better  plan 
future  experiments.  This  section  discusses  three  related  areas  where  Battle  labs  may  want 
to  look  at  improving  their  processes  or  way  of  doing  business:  technology,  process 
reengineering  or  activity  modeling,  and  architecture. 

6.1  Technology 

Since  one  of  the  effective  needs  of  Force  XXI  is  “to  find  innovative  ways  to  apply 
and  combine  current  and  new  technologies  [especially  information  technologies]  for 
warfighting,”  it  is  important  that  Battle  labs  have  an  organized  and  understandable 
approach  to  their  technology  efforts.  This  means  that  Battle  labs  need  to  be  able  to 
explain  and  justify  their  technology  efforts  and  initiatives,  so  several  viewpoints  on 
defining  technology,  and  information  technology  in  particular,  follow. 

Technology  is  the  organization  and  application  of  scientific  and  engineering 
knowledge  to  enhance  some  human  activity  such  as  warfare.  Technology  often  extends  or 
improves  some  human  or  natural  process,  such  as  the  extension  of  a  soldier’s  natural  night 
vision  abilities  by  night  vision  goggles.  In  other  words,  technology  helps  people  do  things. 
A  technology  trend  is  the  general  direction  that  the  enhancement  of  some  human  activity 
by  science  takes  over  time.  To  be  a  significant  trend,  there  must  be  some  order  of 
magnitude  of  enhancement.  For  example,  some  activity  must  be  made  faster,  easier,  or 
better  by  severalfold  or  more.  Sometimes  a  significant  trend  in  technology  is  capable  of 
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transforming  some  human  activity  —  the  activity  can  now  be  done  in  an  entirely  new  and 
different  way. 

Information  technology  is  the  application  of  scientific  and  engineering  knowledge 
to  help  people  work  with  data,  information,  and  knowledge.  A  more  technical  definition 
of  information  technology  is  that  it  is  the  acquisition,  storage,  processing,  transmission, 
and  representation  of  vocal,  pictorial,  textual,  and  numeric  information  by 
microelectronics,  computers,  and  telecommunication  technologies  (Armstrong,  1994,  pp. 
68-71).  Important  questions  for  the  Battle  labs  to  answer  are  what  significant  trends  and 
developments  in  technology  in  general,  and  information  technology  in  particular,  should  be 
leveraged  to  improve  the  activities  and  capabilities  that  are  important  to  their  battlefield 
areas  of  concern?  To  accomplish  this  task,  Batde  Labs  need  a  logical  and  understandable 
process  for  examining  technology  innovation. 

Battle  Labs  should  consider  adopting  a  systematic,  life-cycle  process  for  the 
identification,  assessment,  and  preliminary  implementation  of  technology.  This 
systems  approach  has  seven  (7)  important  and  related  steps  (Sage,  1992,  p.  104). 

•  Scouting 

•  Documentation 

•  Assessment 

•  Selection 

•  Tracking 

•  Disengaging 

•  Supporting 
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Scouting  involves  the  identification  of  requirements  for  candidate  technologies. 
To  accomplish  this,  the  Battle  Labs  need  “technology  scouts”  out  in  the  commercial 
sector,  where  the  rapid  advances  in  information  technology  are  occurring,  who  can  know 
the  Army  and  the  Battle  Labs  functional  areas  and  can  also  understand  and  speak  in 
technical  terms.  Documentation  involves  capturing  information  about  the  warfighting 
need  for,  and  the  feasibility  of,  the  technologies  identified  by  scouting.  Assessment  is  a 
formal  evaluation  of  the  technologies  to  collect  information  which  can  be  used  to  make  a 
selection. 

Selection  is  the  decision  to  allocate  scarce  resources  for  initial  development  and 
implementation  of  chosen  technologies  for  specific  purposes.  Tracking  is  the  monitoring 
of  the  progress  of  the  technical  development  of  the  technology  and  its  implementation. 
Disengaging  is  the  step  in  the  process  which  realizes  that  technology  ventures  are  often 
risky  and  need  to  be  abandoned  when  risk  exceeds  certain  limits.  Also,  when  technology 
projects  have  been  successfully  transferred,  resources  should  be  directed  at  new  projects. 
Supporting  is  the  final  step  in  the  process,  where  the  technology  is  successfully 
transferred  to  another  responsible  element  in  the  organization,  or  where  some  meaningful 
operational  implementation  is  achieved.  The  next  section  describes  a  way  to  help  Battle 
labs  understand  where  and  how  they  can  apply  technological  advances  to  the  battlefield 
activities  that  they  oversee. 

6.2  Reengineering  Processes  and  Activity  Modeling 

To  help  improve  Battle  Lab  processes  and  organize  knowledge  for  Force  XXI 
decision  makers  about  streamlining  battlefield  activities  and  applying  new  technologies  to 
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warfighting,  we  demonstrate  the  activity  modeling  technique  IDEFO  (pronounced  eye- 
deaf-zero).  An  activity  model  is  a  hierarchical  structure  used  to  describe  activities  and 
their  relationships.  A  completed  activity  model  graphically  depicts  the  specific  steps, 
operations,  and  information  needed  to  perform  an  activity.  Activity  modeling  could  be 
very  beneficial  to  the  Battle  Labs  in  two  ways:  to  study  battlefield  activities  and  to 
examine  their  own  internal  processes.  Using  activity  models  in  these  two  areas  would  help 
to: 


•  Identify  redundant  battlefield  activities 

•  Find  ways  to  eliminate  unnecessary  actions  and  streamline  processes 

•  Find  opportunities  for  inserting  technology  into  battlefield  activities 

•  Evaluate  activities  in  terms  of  their  value-added  and  costs 

It  is  important  to  understand  that  an  activity  is  defined  as  “the  transformation  of 
inputs  into  outputs  performed  by  mechanisms  under  the  constraints  set  by  controls”  and 
that  the  diagrams  are  set  up  in  the  Input-Control-Output-  Mechanism  (ICOM)  format 
shown  in  Figure  6.1. 


Figure  6.1  ICOM  Diagram 
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Shown  below  is  our  activity  model  of  leading  battle  at  the  company  level.  First,  we 
subdivided  the  activity  of  leading  battle  into  three  steps  using  a  node  tree  diagram. 


We  then  broke  the  three  steps  of  leading  battle  down  into  individual  steps.  These 
trees  can  be  found  in  Appendix  C.  After  making  the  node  trees,  we  constructed  the 
decomposition  diagrams.  For  each  branch  of  a  node  tree,  there  is  a  corresponding 
decomposition  diagram.  Figure  6.3  is  a  decomposition  diagram  for  the  node  tree  in  Figure 
6.2.  Note  that  each  decomposition  diagram  is  labeled  with  an  activity  designation  (AO), 
the  name  of  the  activity  (Lead  Battle),  and  the  viewpoint  from  which  the  activity  is 
constructed  (Company  Commander).  The  diagram  contains  the  details  of  the  next  level 
subordinate  activities  (Al,  A2,  A3)  which  comprise  the  AO,  Lead  Battle,  activity. 
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Figure  6.3  Decomposition  Diagram  of  Lead  Battle 


We  went  on  to  construct  decomposition  diagrams  for  all  of  the  node  trees  we  created. 
Diagrams  created  with  a  professional  quality  software  package,  Design/IDEF™,  can  be 
found  in  Appendix  D  and  E.  Even  a  brief  inspection  of  these  diagrams  demonstrates  their 
value.  The  diagrams  provide  a  way  of  understanding  and  explaining  the  details  of  any 
battlefield  activity.  And  this  is  the  first  step  that  must  be  accomplished  before  the  activity 
can  be  re-engineered. 

Leading  a  company  in  batde  is  a  very  complex  process.  Activity  modeling  allows 
us  to  break  the  process  down  into  more  manageable  steps.  We  could  also  use  activity 
modeling  to  examine  how  technology  might  be  integrated  into  a  battlefield  activity  in 
order  to  improve  it  in  some  way.  Inserting  a  new  device  or  process  into  the  model  above 
might  change  the  order,  speed,  and  efficiency  of  leading  a  company  in  battle.  Although 
this  is  a  static  model,  it  can  form  the  basis  for  a  simulation  or  dynamic  model.  There  are 
software  programs  available  on  the  market  today,  such  as  Design/IDEF,  that  can 
automatically  generate  a  fully-executable  simulation  model  by  simply  converting  activity 
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models  into  a  simulation  model.  Some  of  these  simulation  software  packages,  such  as 
ServiceModel™,  even  include  animation  as  part  of  the  output  so  that  users  can  see  the 
simulated  system  in  action.5  A  useful  tutorial  on  how  to  build  activity  models  is  included 
as  Appendix  M. 

6.3  Battlefield  Architecture 

Designing  Force  XXI  so  that  it  has  the  attributes  outlined  in  525-5,  such  as 
tailorable,  rapidly  expansible,  strategically  deployable,  effectively  employable, 
interoperable,  and  modular,  depend  on  defining  a  smart  architecture.  Each  Battle  lab 
should  be  able  to  explain  the  battlefield  and  system  architecture  for  their  areas  of  concern 
and  show  how  it  fits  within  the  overall  Force  XXI  architecture.  Therefore,  some  thoughts 
about  architecture  are  appropriate. 

First,  architecture  is  a  scheme  of  arrangement  or  plan  of  how  all  of  the 
component  parts  of  a  system,  such  as  a  battlefield  operating  system,  fit  and  work  together. 
Architecture  identifies  the  system,  its  subsystems,  and  their  various  components  and 
describes  how  they  are  grouped  together  and  their  relationship  to  each  other. 

Importantly  this  includes  the  identification  and  definition  of  the  interfaces  of  the  system, 
both  external  interfaces(  to  other  battlefield  operating  systems),  and  internal  interfaces  ( 
among  the  various  subsystems  and  components  of  the  system).  Another  important  part  of 
architecture  includes  a  description  of  the  repeated  elements  in  the  design.  These 
repeated  elements  usually  take  the  form  of  standards  that  various  components  of  the 


5  Design/IDEF  is  a  registered  trademark  of  Meta  Software  Corporation,  Cambridge  MA  and  ServiceModel 
is  a  registered  trademark  of  ProModel  Corporation. 


system  must  meet  so  that  system-wide  advantages,  such  as  interchangeability  or 
modularity,  can  be  achieved. 
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For  a  complete  description  of  the  architecture  of  a  system,  there  are  three 
important  perspectives.  These  three  views  are  the  functional,  physical,  and  operational 
architecture.  The  functional  architecture  describes  the  various  functions  that  a  system 
and  its  components  performs  and  diagrams  how  they  relate  to  each  other.  A  functional 
flow  block  diagram  or  a  design  EDEF  activity  model  are  excellent  ways  to  diagram  the 
functional  architecture.  The  physical  architecture  of  a  system  shows  the  various  physical 
parts  of  a  system  usually  in  a  hierarchical  block  diagram  schematic.  One  of  the  important 
tasks  of  a  systems  designer  is  to  allocate  the  functions  to  the  various  physical 
components  of  a  system.  But,  perhaps  the  most  important  part  of  architecture  is  the 
operational  architecture  —  how  does  the  system  and  all  its  parts  actually  work  when  it 
operates  and  where  are  its  problems  or  limitations  as  it  operates.  To  examine  the 
operational  architecture  of  a  system,  the  system  must  be  simulated  in  all  its  modes  of 
operation  and  should  be  required  to  interact  with  the  other  systems  that  it  will  have  to 
interoperate  with  in  the  actual  operating  environment. 

When  Battle  Labs  recommend  changes  to  a  battlefield  operating  system,  they  need 
to  see  how  their  recommended  change  will  affect  the  functional,  physical,  and  operational 
architecture.  A  useful  example  for  thinking  about  architecture  is  to  think  about  using  a 
systems  approach  to  design  a  house.  The  physical  architecture  could  be  described  as  the 
various  rooms  of  the  house  and  how  they  are  part  of  the  levels  of  the  house  assuming  we 
are  describing  a  multi-level  house.  Interfaces  are  the  doorways  between  the  rooms.  The 
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repeated  elements  in  the  design  could  be  the  framing  method  used  for  the  construction  of 
the  walls.  Standards  would  be  the  many  standard  components  used  throughout  the  design 
such  as  the  electrical  outlets  or  fixtures  and  the  standard  size  of  studs  used.  The 
functional  architecture  of  the  house,  from  a  user’s  viewpoint  are  such  functions  as 
sleeping,  eating,  washing,  heating  and  cooling,  storage,  and  others.  Now  we  could  make 
very  different  house  designs  by  the  way  we  allocate  these  functions  to  the  various  physical 
components  or  rooms  and  levels  of  the  house. 

But  to  really  understand  how  well  our  designs  might  work,  we  would  have  to  look 
at  the  operational  architecture  of  the  house  and  simulate  how  it  might  work  when  it  was 
actually  being  used.  So  we  might  want  to  simulate  our  house  for  a  family  of  four  and  take 
it  through  a  daily  weekday  routine  or  normal  operating  mode.  If  everyone  wakes  up  at 
about  the  same  time  and  has  to  go  to  one  location  to  wash  and  get  ready  for  work  then  we 
may  have  identified  a  problem  with  our  design,  a  bottleneck  at  the  bathroom.  So  our 
operational  architecture  informs  us  that  we  need  to  duplicate  the  washing  function  in  more 
than  one  physical  location  to  alleviate  the  bottleneck. 

But  we  also  need  to  look  at  other  modes  of  operation  of  the  house.  For  example, 
consider  an  emergency  mode  of  operation  such  as  a  house  fire.  If  the  house  has  only  one 
exit  and  that  exit  is  blocked  by  the  fire,  then  we  have  identified  another  design  problem. 
We  need  to  change  the  physical  and  functional  architecture  by  adding  more  exits  for  use 
especially  during  a  fire  emergency  mode  of  operation.  Although  this  is  a  simple  example, 
it  does  illustrate  the  benefits  of  having  a  thorough  understanding  of  the  physical, 
functional,  and  operational  architecture  of  Force  XXI. 
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7.0  Real  Operations  -  Task  Force  Ranger 

First,  we  want  to  say  that  the  all  of  Task  Force  Ranger  performed  very  heroically 
in  Somalia  which  was  a  very  difficult  operating  environment,  both  tactically  and 
strategically.  However,  it  is  vitally  important  to  understand  real  operations  so  we  can 
gamer  lessons  learned  and  improve  performance  in  future  operations.  This  is  even  more 
true  when  considering  how  to  re-design  a  force  for  the  21st  century  -  the  new  force  should 
capitalize  on  our  current  strengths  and  overcome  any  limitations  that  may  exist.  In  this 
spirit,  about  400  senior  cadets  and  eight  instructors  enrolled  in  a  systems  engineering 
design  course  supervised  by  LTC  Armstrong,  studied  unclassified  reports  of  the  Task 
Force  Ranger  operation  in  Somalia  using  a  systems  engineering  framework.  Each  team 
developed  their  own  interpretation  of  what  went  wrong,  what  went  right,  and  made 
recommendations  for  the  future.  This  section  summarizes  that  work  and  its  results. 

The  major  observations  and  results  of  the  work  of  the  cadets  focused  on  two 
related  areas:  command  and  control  and  information.  Here  are  the  results  in  brief. 
Samples  of  the  work  that  led  to  these  conclusions  are  at  Appendix  L. 


7.1  Information 

From  the  unclassified  readings  available  to  the  cadets,  Task  Force  Ranger 
appeared  to  suffer  from  a  lack  of  information  in  several  key  areas.  First,  there  seemed  to 
be  a  lack  of  knowledge,  or  at  least  a  sufficient  appreciation,  about  how  the  enemy  had 
organized  its  command  and  control  structure  and  the  capabilities  this  simple  but  effective 
organization  gave  the  enemy.  The  enemy  command  and  control  structure,  although 
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technologically  simple,  was  very  effective.  They  used  a  sector  defense  system  linked 
together  by  walkie-talkies,  drums,  and  messengers.  It  was  successful  at  quickly  mobilizing 
many  armed  Somalis  into  the  fight  and  in  coordinating  the  erection  of  a  series  of  barriers 
covered  by  fire  to  entrap  the  extraction  forces  and  block  friendly  reaction  forces. 


As  can  be  seen  in  Figure  7.1,  Mogadishu,  like  most  underdeveloped  urban  areas 
lends  itself  to  a  sector  defense  arrangement.  The  sector  defense  is  not  new  at  all  and  has 
often  been  used  especially  in  low  intensity  conflict.  The  area  to  be  defended  is  divided  up 
into  sectors  or  blocks.  A  sector  commander  is  appointed  for  each  sector  in  the  defended 
area.  In  brief,  sector  commanders  establish  communication  links  between  each  other  and 
the  forces  they  control.  When  a  sector  is  threatened,  the  threatened  sector  sounds  the 
alarm  which  is  relayed  to  other  sectors  so  they  know  which  sector  is  in  danger. 
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Neighboring  sectors  know  in  advance  that  their  responsibility  is  to  quickly  mobilize 
reinforcements  to  the  threatened  sector  as  shown  in  Figure  7.2.  Oudying  sectors,  more 
removed  from  the  threat,  are  tasked  to  block  likely  routes  that  extraction  or  reaction 
forces  might  take. 


The  reason  the  sector  defense  works  so  well  is  that  the  response  of  the  defenders 
can  be  planned  and  rehearsed  well  in  advance  so  that  their  reactions  to  a  threat  can  be 
executed  with  great  speed  and  flexibility.  A  vulnerability  of  the  sector  defense  is  that  it 
can  be  distracted  by  false  alarms  or  saturated  by  multiple  simultaneous,  or  nearly 
simultaneous,  threats.  Most  sector  defenses  only  plan  to  respond  to  one  threat.  Once  the 
sectors  have  been  alerted  to  respond  to  a  given  threat  in  a  certain  sector  it  is  very  difficult 
for  the  defenders  to  reorganize  the  response  to  subsequent  threatened  sectors. 
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Since  all  of  the  decisions  of  the  sector  commanders,  and  the  actions  of  the  forces 
they  control,  are  pre-planned  in  advance  and  well-rehearsed,  it  is  very  difficult  for  an 
intruding  force,  once  detected,  to  get  inside  the  observe-decide-act  cycle  of  the  sector 
defense.  Once  the  battle  is  joined,  the  intruding  force  is  at  a  big  disadvantage  because  any 
actions  they  try  to  carry-out  are  in  the  enemy’s  neighborhood.  This  means  that  all  of  their 
actions  are  under  constant  enemy  observation  and  perhaps  fire  as  well.  On  unfamiliar  and 
dangerous  territory,  the  intruding  force  has  to  be  cautious  and  take  more  time  to  plan  and 
take  actions.  The  sector  defenders  know  the  territory  by  heart  and  can  quickly  carry  out 
many  different  actions  that  they  have  planned  in  advance. 

Another  indicator  of  the  lack  of  information  was  the  apparent  under  estimation  of 
the  Somalia  capabilities  for  using  innovative  tactics.  For  example,  not  only  was  the 
Somali  skill  at  organizing  a  sector  defense  under  rated,  but  their  ability  to  train  and  employ 
soldiers  in  groups  to  fire  salvos  of  rocket  propelled  grenade  launchers  at  helicopters  was 
not  anticipated. 

The  third  indicator  of  the  lack  of  information  was  the  way  that  one  of  TF  Ranger’s 
important  subsystems  was  apparently  operating,  their  intelligence  subsystem.  Long  ago,  it 
was  recognized  by  the  Germans  that  their  are  several  subsystems  that  are  very  important 
to  the  operation  of  an  armed  force  and  that  these  subsystems  are  so  vital  that  they  decided 
to  put  a  staff  officer  in  charge  of  each  one  of  them.  We  are,  of  course,  talking  about  the 
SI,  S2,  S3,  and  S4  who  are  in  charge  of  the  personnel,  intelligence,  operations,  and  supply 
subsystems  of  a  military  unit  or  system. 
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One  of  the  breakdowns  in  TF  Ranger  appeared  to  be  in  the  intelligence  subsystem. 
From  a  systems  viewpoint,  we  know  that  often  failures  occur  in  a  system  because  of 
interface  problems  with  other  systems  or  due  to  faulty  interactions  among  the  components 
parts  or  subsystems  of  a  system.  In  special  operations,  especially  leader- snatch  type 
operations,  intelligence  is  crucial.  The  intelligence  subsystem  of  TF  Ranger  was 
depending  heavily  on  a  dedicated  interface  to  one  specific,  external  human  intelligence 
source.  That  interface  broke  down  when  the  source  shot  himself  in  the  head  shortly 
before  the  operation.  The  planners  of  the  operation  apparently  had  not  prepared 
alternative  sources  to  compensate  for  the  possible  loss  or  compromise  of  this  one  source. 
Further,  the  intelligence  sources  external  to  TF  Ranger  were  unable  to  provide  needed 
information  on  the  whereabouts  of  Aidid  and  his  top  aides  on  a  consistent  enough  basis  to 
make  the  chances  for  success  of  the  operation  higher.  Despite  these  problems  with 
information,  the  first  phase  of  the  TF  Ranger  operation  was  fairly  successful  because  they 
were  able  to  locate  and  capture  some  of  Aidid  top  lieutenants.  Unfortunately,  command 
and  control  difficulties  so  complicated  the  rest  of  the  operation,  that  success  quickly 
evaporated. 

7.2  Command  and  Control 

The  first  problem  with  the  command  and  control  structure,  aside  from  the 
complicated  structure  of  UN  multinational  forces  with  US  special  operations  forces,  US 
Army  forces  and  US  Marines,  was  the  rules  of  engagement  and  procedures  for  making 
changes  to  them.  Apparently,  the  rules  of  engagement  stressed  minimizing  casualties  to 


32 


the  enemy  to  the  extent  that  even  when  the  helicopter  pilots  saw  Somalis  passing  out 
weapons  and  RPGs  to  their  people,  they  did  not  fire  on  them  to  disperse  them  and  prevent 
them  from  organizing  themselves  for  the  fight.  By  the  time  it  was  clear  that  the  rules  of 
engagement  did  not  make  any  sense  and  needed  to  be  changed,  it  was  too  late  and 
helicopters  were  already  fatally  hit.  Still  the  situation  may  have  been  stabilized  if  more 
firepower  from  the  air  could  have  been  brought  in  but  apparently  none  had  been  planned 
for  and  the  commander  on  the  scene  apparently  did  not  know  how  to  change  the  rules  of 
engagement  or  was  too  heavily  engaged  to  worry  about  it. 

The  next  command  and  control  problem  was  that  TF  Ranger  had  no  effective  way 
to  direct  and  control  their  forces  in  the  twisted  streets  and  confusing  urban  terrain  of 
Mogadishu.  When  a  helicopter  was  shot  down  and  elements  of  the  force  were  sent  to  its 
rescue,  they  could  not  navigate  their  way  to  the  downed  helicopter  even  though  it  was 
only  several  hundred  yards  away.  By  the  time,  elements  could  reach  the  helicopter,  the 
Somalis  had  arrived  with  many  of  their  troops. 

Another  command  and  control  problem  was  the  apparent  poorly  planned  and 
organized  procedure  for  controlling  the  extraction  and  reaction  forces.  Once  the 
operation  started  to  ran  into  difficulty,  there  should  have  been  a  rapid  extraction  of  all 
personnel  by  the  quickest  means  available  to  designated  rallying  points.  As  soldiers  fought 
bravely  to  save  each  other,  control  of  this  aspect  of  the  operation  deteriorated.  As  the 
vehicle  ground  route  out  of  the  area  became  next  to  impossible,  there  did  not  seem  to  be  a 
good  branch  or  sequel  to  the  primary  extraction  plan.  Reaction  forces  seemed  to  be  slow 
getting  notification  and  slow  to  arrive  where  they  could  do  any  good.  Part  of  command 
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and  control  is  making  and  disseminating  plans  that  have  been  wargamed  and  well 
rehearsed.  Perhaps  the  concern  for  secrecy  prevented  the  proper  preparation  of  the 
reaction  forces.  But  with  the  situation  extant  in  Somali,  there  should  have  been  a  daily 
standing  alert  or  reaction  forces  with  specified  timelines  that  could  have  been  chopped  to 
the  operation  at  a  moments  notice,  on  command.  Proper  information  on  the  structure  of 
the  enemy’s  sector  defense  and  capabilities  should  have  highlighted  the  special  needs  of 
the  reaction  force  such  as  heavy  armor  to  break  through  barriers  and  helicopters  for  rapid 
fire  support  and  extraction  of  personnel. 

What  can  we  do  to  make  sure  that  future  operations  are  more  successful?  In  one 
sense,  we  could  say  that  we  should  try  to  avoid  these  very  difficult  operating  conditions. 
But  realistically,  we  should  know  that  the  Army  exists  to  go  into  difficult  situations.  So 
the  answer  has  to  be  that  we  need  to  improve  our  knowledge  of  command  and  control, 
not  just  our  knowledge  of  how  we  ought  to  operate  and  make  decisions,  but  also  make 
sure  that  before  we  go  into  any  operation  that  we  have  a  thorough  understanding  of 
how  the  enemy  command  and  control  system  works.  This  means  we  need  to  know 
how  the  enemy  gathers  and  transmits  information,  makes  decisions,  and  takes 
action.  Also,  we  need  to  significantly  enhance  the  information  capabilities  of  our  forces. 
Stovepipe,  single  interface  connections  to  external  information  sources  about  the  enemy 
should  not  be  acceptable  practices  for  any  military  units  in  the  information  age  especially 
special  operations  units. 

Some  of  the  analysis  by  the  cadets  may  not  be  entirely  correct  because  they  were 
piecing  together  unclassified,  open  source  reports  about  Task  Force  Ranger.  Certainly 
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insiders  who  have  access  to  classified  information  can  probably  point  out  errors  in  fact  but 
given  the  same  information  that  the  cadets  had  to  use  for  this  analysis,  even  the  insiders 
would  probably  admit  that  the  cadet  results  appear  very  reasonable.  Again,  the  cadets  had 
great  respect  for  the  bravery  of  the  soldiers  in  Task  Force  Ranger.  Their  motivation  in 
studying  this  example  was  to  learn  so  they  could  be  the  best  leaders  they  can  be.  In  fact, 
some  of  the  cadets  who  participated  in  this  analysis  are  now  getting  their  chance  to  put 
these  ideas  into  practice  in  Bosnia  without  the  advantage  of  hindsight.  Perhaps  this 
exercise  in  hindsight  will  give  them  the  foresight  they  need  to  lead  bravely  and  wisely. 
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8.0  Recommendations  and  Conclusions 

For  the  information  in  this  report  to  be  useful,  it  is  essential  that  the  Battle  Labs 
take  ownership.  In  other  words,  the  Battle  Labs  must  take  hold  of  these  ideas  and 
implement  them  as  regular  processes.  The  use  of  objectives  trees,  a  common  terminology, 
crosswalks  of  AWE  results  with  future  doctrine,  and  activity  modeling  will  all  help  in 
determining  what  the  Army  of  the  21st  century  should  be  like.  We  believe  that  the 
following  recommendations  will  help  in  structuring  Force  XXI.  We  display  the  six  major 
objectives  for  this  work  in  shaded  boxes  along  with  the  major  findings  and 
recommendations  summarized  below  each  objective  in  clear  text  boxes. 


To  scope  and  bound  Force  XXI  design  efforts. 


To  scope  the  Force  XXI  design  effort,  we  identified  the  needs,  objectives,  and 
criteria  of  Force  XXI  from  a  systems  viewpoint.  Effective  needs  are  critical  because  the 
definition  of  a  successful  design  effort  is  meeting  or  exceeding  the  effective  needs  of  the 
client  or  stakeholder  group  in  a  cost-effective,  high-quality  way.  So  the  effective  needs 
must  answer  the  question,  “Why  are  we  redesigning  the  Army  to  Force  XXI?”  Five 
statements  drawn  with  some  modification  from  TRADOC  Pamphlet  525-5,  in  our  opinion, 
answer  this  question.  They  are: 

1.  To  be  trained  and  ready  to  win  the  first  land  battle  with  fewer,  more  economical 
but  more  capable  forces. 

2.  To  be  rapidly  tailorable,  rapidly  expansible,  strategically  deployable,  and 
effectively  employable  as  part  of  a  joint  and  multinational  team  to  achieve 
decisive  results  in  future  war  and  other  operations  in  all  environments. 

3.  To  win  simultaneous  operations  against  foes  of  varying  capabilities. 

4.  To  find  innovative  ways  to  apply  and  combine  current  and  new  technologies, 
especially  information  technologies,  for  warfighting. 

5.  To  win  tactical  battles  quickly  and  decisively  by  maximizing  information  and 
combat  power  to  dominate  the  battlespace. 
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RECOMMENDATION  1:  That  the  effective  needs  of  the  Force  XXI 
design  effort  be  clearly  communicated  to  the  Army  to  unite  design  efforts 
across  organizations  toward  a  common  top-level  goal.  We  propose  the 
effective  needs  outlined  above  as  a  draft  for  senior  decision  makers  to 
sharpen  or  revise. _ 

To  make  Force  XXI  a  reality,  there  are  many  lower  level  goals  or  objectives  that 
should  be  pursued  in  a  coordinated  fashion  to  meet  or  exceed  the  effective  needs  of  Force 
XXI.  By  parsing  TRADOC  Pamphlet  525-5,  we  identified  more  than  seventy-five  (75) 
objectives  that  Battle  Labs  and  other  Army  organizations  may  want  to  pursue.  We 
structured  these  objectives  into  a  conflict  matrix  of  six  objective  trees  or  hierarchies  to 
reflect  tactical,  operational,  and  strategic  concerns  across  war  and  operations  other  than 
war.  These  objectives  trees  represent  everything  that  the  Army  must  make  significant 
progress  on  to  make  Force  XXI  operations  a  reality. 


RECOMMENDATION  2:  That  Battle  Labs  and  other  Army 
organizations  identify  objectives  and  structure  their  objectives  into 
objective  trees,  similar  to  the  ones  contained  in  this  report,  so  they  can 
have  a  coherent  picture  of  everything  they  intend  to  accomplish  to  make 
significant  progress  toward  Force  XXI.  _ 

One  of  the  findings  from  the  Battle  Lab  visits  was  that  they  had  difficulty 
articulating  their  objectives  and  understanding  the  objectives  that  they  shared  with  other 
organizations.  It  is  hard  to  make  progress  toward  a  goal  when  you  don’t  know  where  you 
are  going.  Note  that  this  does  not  conflict  with  the  idea  of  a  “journey  not  a  destination.” 
The  kind  of  objectives  that  are  outlined  in  this  report  are  statements  of  intent  that  allow 
for  many  different  alternatives  and  do  not  identify  specific  programs,  systems,  or 
technologies. 

Again,  the  objectives  in  this  report  are  draft  objectives,  mostly  extracted  from 
TRADOC  Pamphlet  525-5  and  should  be  considered  as  illustrative  examples.  For  the 
objectives  to  be  worthwhile,  each  Battle  Lab  should  create  their  own  set  of  Force  XXI 
objectives  and  then  their  should  be  a  master  integration  effort  of  the  objectives  across  the 
Battle  Labs.  The  final  structure  of  objectives  should  be  integrated  into  subsequent 
revisions  of  Army  doctrine  so  that  organizations  can  pull  together  to  accomplish  them. 
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RECOMMENDATION  3:  That  each  Battle  Lab  develop  meaningful, 
measurable  criteria  for  their  objectives.  In  this  way,  Battle  Labs  can 
determine  how  much  progress  they  are  making  towards  achieving  their 
objectives.  _ 

The  objectives  trees  will  help  Battle  labs  develop  meaningful  measures  that  they  can  use  in 
experiments.  Although  higher  level  objectives  may  be  difficult  to  measure,  it  should  be 
possible  to  develop  measurable  criteria  for  each  lower  level  objective.  A  weighted 
combination  of  lower  level  criteria  can  be  used  to  measure  a  higher  level  objective. 

RECOMMENDATION  4:  That  Battle  Labs  should  construct  anti¬ 
objective  trees  which  show  objectives  that  counter  the  enemy’s  objectives. 

A  sample  anti-tree  is  in  the  report.  _ 

To  bound  a  design  means  to  identify  the  constraints,  parameters,  and  variables  of 
the  problem.  Constraints  are  the  limits  that  are  placed  on  the  design  solution  and  help  to 
focus  the  design  efforts  toward  feasible  options.  Parameters  are  elements  of  the  design 
which  can  be  changed  to  help  define  competing  alternatives  but  they  do  not  change  once  a 
particular  alternative  is  in  operation.  For  example,  the  number  of  tanks  in  a  tank  company 
or  the  number  of  soldiers  in  any  infantry  squad  are  design  parameters  of  a  force  that  can 
be  changed  to  define  different  force  options. 

Variables  are  important  quantities  that  we  want  to  monitor  as  the  design 
alternative  actually  operates  or  is  simulated.  For  example,  we  want  to  know  the  cost  of 
various  force  design  options  in  terms  of  friendly  casualties  suffered  in  likely  conflict 
scenarios.  To  make  meaningful  design  progress,  we  need  to  know  what  can  and  what 
cannot  be  changed  and  how  important  variables  are  affected  by  different  design  choices. 
Here  are  some  sample  design  constraints,  parameters,  and  variables  for  Force  XXI,  some 
of  which  we  extracted  from  TRADOC  Pamphlet  525-5: 

Constraints  (Things  we  must  adhere  to  as  we  design  force  options.) 

•  Keep  a  division  base 

•  Maintain  soldier  focus 

•  Full  dimensional  force 

•  Change  leader-to-led  ratio 
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•  Modular  combat  support  and  combat  service  support 

•  Smaller  staffs 

•  Smaller  units 

•  Mobile,  multi-functional  command  posts 

•  Incorporate  cybernetic  or  feedback  mechanisms  for  adaptation  and  innovation 

•  And  more 

Parameters  (Things  we  can  change  to  create  different  options.) 

•  Number  of  command  echelons  in  a  division 

•  Number  of  control  elements  at  each  command  echelon  (e.g.,  tactical  command  posts) 

•  Number  of  staff  elements  at  each  command  echelon 

•  Type  of  staff  elements  at  each  echelon 

•  Number  of  staff  personnel  in  each  element 

•  Number  of  units  in  each  echelon  of  command 

•  Type  of  units  in  each  echelon 

•  Number  of  systems  (e.g.,  tank,  Infantry  Fighting  Vehicle)  in  each  unit 

•  Type  of  systems  in  each  unit 

•  Number  of  soldiers  in  each  crew  or  squad 

•  Type  of  soldiers  in  each  crew  or  squad 

•  Type  of  units  in  the  division  base 

•  Size  of  units  in  the  division  base 

•  Number  of  functions  performed  at  each  echelon,  unit,  or  element 

•  Type  of  function  performed  at  each  echelon,  unit,  or  element. 

•  And  more 

Variables  (Things  we  must  monitor  when  we  exercise  or  simulate  force  options) 

•  Amount  of  battlespace  that  can  be  dominated  or  controlled  by  the  force 

•  Force  recognition  time  (time  that  it  takes  for  the  force  to  recognize  significant 
battlefield  situations) 

•  Force  response  time  (time  that  it  takes  for  the  force  to  respond  to  significant  battlefield 
situations  once  recognition  has  occurred) 

•  Force  tempo  (the  number  of  significant  battlefield  situations  that  the  force  can 
recognize  and  respond  to  in  some  specified  unit  of  time) 

•  Number  of  enemy  systems  killed 

•  Number  of  friendly  casualties 

•  Consumption  rates  (ammunition,  fuel,  food,  expendable  supplies) 

•  And  many  more 

In  addition  to  internal  thinking  about  how  the  Army  can  change  itself,  we  need  some  “out 
of  the  box”  thinking  about  how  the  other  services,  that  are  part  of  the  joint  team,  could 
change  to  make  the  overall  team  more  efficient  and  effective.  For  example,  are  there 
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functions  or  activities  that  take  up  a  significant  part  of  the  Army’s  budget  that  should  be 
offloaded  to  another  service  or  are  their  better  ways  that  other  services  could  accomplish 
their  functions  and  activities  that  would  generate  a  savings  that  could  be  put  to  good  use 
by  the  Army.  Perhaps  there  are  functions  and  activities  that  the  Army  performs  for  other 
agencies  that  should  be  done  on  a  reimbursable  basis.  The  systems  point  of  view  calls  for 
examining  not  just  redesigning  the  Army  put  also  understanding  how  the  Army  should  fit 
and  work  with  all  the  other  systems  in  its  operating  environment. 


RECOMMENDATION  5:  That  Battle  Labs,  in  their  areas  of  expertise, 
help  senior  decision  makers  identify  the  design  constraints  that  must  be  met 
and  the  design  parameters  that  can  be  manipulated  to  create  viable  design 
options.  Also,  that  Battle  Labs  determine  how  the  variables  of  interest 
change  for  different  design  options  across  different  operating  environments 
and  scenarios.  This  requires  that  Battle  Labs  have  access  to  a  robust 
modeling  and  simulation  capability. _ 


IITp  Mp  establish  a  coherent  framework  and  consistent  terminology  for  Force  XXlIl 


RECOMMENDATION  6:  That  the  terms  and  definitions  for  Force  XXI 
Operations  doctrine  be  simplified  as  much  as  possible  since  doctrine  needs 
to  be  soldier  friendly.  Currently  there  are  many  compound  terms  with 
lengthy  definitions.  Sample,  simplified  definitions  of  some  key  terms  and 
concepts  are  in  the  report. _ 


RECOMMENDATION  7:  That  a  cybernetic  or  feedback  control  type 
paradigm  of  military  conflict  be  incorporated  into  Army  doctrine  by  using 
simple  diagrams  of  sense-decide-act  to  help  soldiers  understand  the 
relationship  between  information  operations  and  combat  operations.  A 
sample  diagram  is  in  the  report. _ 
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To  help  unde rs>f  undpastA rmv  Warfighting  Experiments  (AWT«||Vdvaneed 
Technology  Demonstrations  (ATDs),  and  real  operations  in  terms  of  their  impa« 
designing  Force  XXL 


RECOMMENDATION  8:  That  the  results  of  Army  Warfighting 
Experiments  (AWEs)  be  crosswalked  with  the  main  ideas  in  TRADOC 
Pamphlet  525-5  to  identify  trends  that  confirm  or  refute  doctrinal  ideas  and 
to  identify  knowledge  gaps  where  we  need  additional  experimentation.  A 
sample  method  to  accomplish  this  with  a  crosswalk  and  results  matrix  is  in 
the  report. 


RECOMMENDATION  9:  That  Battle  Labs  analyze  recent  real 
operations  to  understand  shortcomings  associated  with  their  areas  of 
oversight.  A  sample  analysis  of  a  recent  operation  is  in  the  report.  To 
accomplish  this,  the  Battle  Labs  will  need  access  to  information  about  these 
operations,  including  perhaps  real-time  observers  and  qualified  military 
operations  analysts. 


To  help  improve  Battle  Lab  prjnilill 


RECOMMENDATION  10:  That  Battle  Labs  develop  a  more  detailed 
understanding  of  the  battlefield  activities  they  are  trying  to  improve  by 
constructing  activity  models  (IDEFO)  of  their  battlefield  activities.  A 
sample  battlefield  activity  model  for  leading  infantry  battle  complete  with 
node  trees  and  decomposition  diagrams  is  in  the  report. 


This  does  not  imply  that  Battle  Labs  do  not  understand  their  battlefield  activities.  Rather, 
it  means  that  the  Battle  Labs  have  difficulty  explaining  these  activities  to  others  and  in 
communicating  their  reasons  and  justifying  the  value-added  of  particular  technologies  or 
other  changes  they  want  to  make  to  the  way  they  accomplish  their  battlefield  activities. 


RECOMMENDATION  11:  That  Battle  Labs  adopt  and  use  a  systemic, 
life-cycle  process  for  the  identification,  assessment,  and  preliminary 
implementation  of  technology.  This  life-cycle  has  seven  (7)  important  and 
related  steps:  Scouting,  Documentation,  Assessment,  Selection, 
Tracking,  Disengaging,  and  Supporting.  More  details  on  how  this 
process  works  is  in  the  report.  To  accomplish  this,  the  Battle  Labs  will 
need  “Technology  Scouts”  out  immersed  in  the  commercial  sector  who 
know  the  Army  and  can  understand  technology  and  its  potential 
applications  to  warfighting. _ 
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RECOMMENDATION  12:  That  the  Battle  Labs  develop  a  better 
understanding  of  battlefield  and  system  architecture.  This  includes  not  just 
the  physical  and  functional  architecture  but  also  the  operational 
architecture  for  their  area  of  concern—  how  does  it  work  when  it  is 
actually  put  into  operation  and  where  are  the  problems  that  arise  during 
different  modes  of  operation. _ 


The  recommendations  from  this  work,  if  put  into  action,  should  help  support  the  Battle 
Labs  and  other  Army  organizations  and  offices  to  make  and  evaluate  progress  on  Force 


XXI 
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Appendix  A 
Objectives  Trees  -  War 


To  win  tactical  battles  quickly  and 
decisively  by  maximizing  the  application 
of  combat  power  to  dominate  the  battlespace 
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To  win  simultaneous  operations 
against  foes  of  varying  capabilities 
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Objectives  Trees 
Operations  Other  Than  War 


To  be  prepared  to  combat  foes 
who  employ  terrorism,  insurgency, 
or  partisan  warfare 
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Anti-Objectives  Tree 
War  at  the  Tactical  Level 


To  win  tactical  battles  quickly  and 
decisively  by  maximizing  the  application 
of  combat  power  to  dominate  the  battlespace 
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Node  Tree  Diagrams  for  the  Activity  of  Lead  Battle 
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Decomposition  Diagrams  for  Lead  Battle 
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List  of  Force  XXI  Objectives  from  TRADOC  Pamphlet 

525-5 


OBJECTIVES 


# 

OBJECTIVE 

Page  525-5 

1 

To  be  prepared  to  fight  unconventional  forces 

2-5 

2 

To  be  prepared  to  operate  against  terrorism, 
insurgency,  and  partisan  warfare 

» 

3 

To  exploit  reserve  components 

3-1 

4 

To  anticipate  movement 

i 

5 

To  ensure  skillful  preposition 

i 

6 

To  maximize  lethality 

i 

7 

To  maximize  survivability 

i 

8 

To  make  forces  lighter 

i 

9 

To  conduct  deeper  operations 

i 

10 

To  anticipate  possible  commitments 

3-2 

11 

To  maximize  use  of  other  service  assets 

i 

12 

To  use  minimum  force  necessary 

i 

13 

To  improve  joint  and  interagency  operations 

i 

14 

To  increase  joint  and  multi-national  connectivity 

i 

15 

To  use  Army  HQs  as  efficient  joint  force  command  mechanisms 

i 

16 

To  expand  linguistic  knowledge  and  cultural  awareness 

i 

17 

TO  BE  TRAINED  AND  READY  TO  WIN  THE  LAND  BATTLE 

i 

18 

To  transition  from  war  to  OOTW 

i 

19 

To  gain  information  and  accurate  and  timely  perceptions  of  the  battlespace 

3-3 

20 

To  minimize  cost  in  lives 

3-4 

21 

To  conduct  a  variety  of  missions  in  different  operational  circumstances  and 
geographic  environments 

i 

22 

To  employ  both  hierarchial  and  internetted  information  systems 

3-5 

23 

To  control  people 

3-8 

24 

To  control  terrain 

i 

25 

To  recognize/view  the  battlespace 

l 

26 

To  conduct  simultaneous  engagements  by  a  variety  of  joint 
warfighting  systems 

3-9 

27 

To  empty  the  battlespace 

i 

28 

To  be  capable  of  using  fires(both  direct/indirect  and  manned/unmanned) 
to  gain  the  advantage 

i 

29 

To  reduce  friendly  force  vulnerability  by  increasing  the  dispersion 
and  numbers  of  the  force 

i 

30 

To  conduct  maneuver  by  use  of  both  fires  and  rapid  physical  mass  and 
dispersion  of  ground  forces 

i 

31 

To  overload  the  enemys  ability  to  cope  by  presenting  an  overwhelming 
number  of  actions  throughout  the  depth  of  the  battlefield 

3-11 

32 

To  develop  a  logistics  system  that  is  versatile,  deployable,  and  expandable 

i 

33 

Tempo 

3-19 

34 

To  employ  non-lethal,  noncrippling,  temporary  disabling  weapons  and 
high-tech,  crowd  dispersal  systems 

3-23 

35 

To  be  versatile 

4-2 

36 

NEED-smaller  and  more  lethal,  flexible  force 

4-3 

37 

To  be  prepared  to  make  decisions,  such  as  those  concerning  ROE 

4-4 
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CDT  H.  Jay  Brock 
LTC  James  E.  Armstrong  Jr. 


OBJECTIVES 


38 

To  enhance  survivability  and  protection-LIST 

4-7 

39 

To  conduct  quick,  decisive,  highly  sophisticated,  operations 

4-11 

40 

To  execute  limited  protracted  operations  against  a  low  tech  army 

1 

41 

To  know  enemy  operating  procedures 

42 

To  understand  enemy  leaders 

43 

To  know  the  terrain 

44 

To  understand  the  people 

45 

To  know  the  culture 

46 

To  monitor  the  impact  of  enemy  actions  on  the  people 

47 

To  monitor  the  impact  of  friendly  actions  on  the  people 

48 

To  monitor  the  impact  of  friendly  actions  on  enemy  leaders 

49 

To  understand  the  economy 

50 

To  know  the  enemy's  power  or  political  structure 
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List  of  Force  XXI  Terms 


FORCE  XXI  TERMS 


61- 


Five  Characteristics 

Doctrinal  Flexibility 

Stategic  Mobility 

Tailorability  and  Modularity 

Joint,  Mulitnational,  and  Interagency  Connectivity 

Versatility  in  War  and  OOTW 

Pattern  of  Knowledge-Based  Warfare 
Plan 
Recon 
Control 
Act 

Recover 

Battle  Dynamics 

Battle  Command 
Battlespace 

Depth  and  Simultaneous  Attack 
Early  Entry 

Combat  Service  Support 
Force  XXI  Parameters 

1.  Battle  Command  based  on  real-time,  shared,  situational  awareness 

2.  Responsibility  will  remain  hierarchical;  but  organizations  probably  will  not  remain 
hierarchical  in  a  traditional  sense 

3. Design  will  derive  from  capabilities,  not  from  specific  threat 

4. May  well  have  smaller  building  block.. .more  lethal,  more  versatile,  more  effective. better 

5.  Force  Congruence  from  top  to  bottom 

6.  Units  will  rely  on  electronic  connectivity  vice  geographic  or  physical  connectivity 

7. Will  be  more  strategically  deployable  with  a  full  range  of  early  entry  capabilities 
tailorable  to  a  full  range  of  missions 

Mod  Thrusts 

Win  the  info  War 
Precision  Strike 
Project/Sustain  the  Force 
Protect  the  Force 
Dominate  Maneuver  Battle 
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FORCE  XXI  TERMS 


Force  XXI  Design  Principles 

-  The  Division  will  be  organized  to  optimze  information-based  operations 

-  Dominate  Battlespace:  speed,  space,  and  time 

-  Control  Battlefield  tempo  with  overwhelming  lethality  and  superior  survivability 

-  Mount,  execute,  and  recover  from  operations  simultaneously 

-  Be  capable  of  quick,  decisive  victory  with  minimum  casualties 

-  Be  rapidly  deployable  and  operationally  agile 

-  Enhance  Tailorability  through  modularity  across  the  force 

-  Divert  tasks  that  inhibit  the  division's  primary  mission:  to  fight  and  win  battles  and 
engagements 

-  Be  effective  in  war  and  OOTW  as  part  of  a  joint  and  multinational  team  in  all  operational 
environments 

Force  XXI  Constraints 

Division  Base 
Maintain  Soldier  Focus 
Must  Change  Leader-to-Led  Ratio 
Modular  CS  and  CSS 
Smaller  Staffs 

Mobile,  Multi-functional  command  posts 

Battlefield  Operating  Systems 

Command  and  Control  Warfare 

Maneuver 

Fire  Support 

Air  Defense 

Battle  Command 

Intelligence 

Mobility  and  Survivability 
Combat  Service  Support 

Systems  Life  Cycle  for  Technology 
Scouting 
Documentation 
Assessment 
Selection 
Tracking 
Disengaging 
Supporting 
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Force  XXI  Reference  of  Terms 


TRADOC:  WHERE  TOMORROW’S  VICTORIES  BEGIN 


II 
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Crosswalk  of  Main  Ideas  from  525-5  and  AWEs 


AWEs  and  Main  Ideas  from  TRADOC  Pamphlet  525-5  Crosswalk 
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Main  Ideas  from  525-5 


16.  Advanced  forces  will  achieve 
multiple  operational  objectives  nearly 
simultaneously  throughout  a  theater  of 
operations. 


17.  Simultaneity  and  near-real-time 
military  and  public  communications 
will  blur  and  compress  the  traditional 
divisions  between  strategic, 
operational  and  tactical  levels  of  war. 
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19.  Shared  knowledge  will  improve 
deployability  through  smaller,  more 
precise  tailoring  of  combat  units  and 
support  requirements. 


20.  Aided  by  information  technology, 
organizations  will  tend  to  grow  flatter 
and  less  rigidly  hierarchical. 


21.  Liaison  requirements  will 
logically  increase  in  quantity  and 
complexity. 


22.  By  mastering  information  we  can 
command  operations  at  an  operational 
tempo  that  no  potential  adversary  can 
match. 


23.  Information  about  the  full  effect 
of  full-dimensional  operations  will 
allow  greater  synchronization  of 
effort,  control  of  tempo,  and  control  of 
force  application  by  informing  units 
(and  perhaps  even  enemy  units  to 
convince  them  to  surrender). 


+  =  Confirm 

0  =  No  evidence 

=  Contradict 

Row  of  +S  implies  a  conclusion  that  we  have  a  trend  of  confirming 
evidence  that  the  main  idea  is  sound. 

Row  of  -s  implies  a  conclusion  that  we  have  experimental  results  which 
contradict  the  main  idea  therefore  we  may  need  to  change  the  idea  or 
discard  it  if  we  have  confidence  in  our  resutls. 
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_ Hypothesis _ 

_ If-. _ Then... _  Results  Insights 

within  a  digitized  force  different  increases  in  lethality,  survivability, 

technologies,  doctrine,  and  and  tempo  can  be  gained  across 
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Interim  Briefing  Charts 


Department  of  Systems  Engineering 
United  States  Military  Academy 
West  Point,  New  York  10996-1997 
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Adapted  from  Sage,  Systems  Engineering ,  1992,  p.  79. 


Effective  Needs  of  Force  XXI 
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To  use  the  minimum  force  necessary. 
To  maximize  survivability. 


Force  XXI  Objectives  (2) 
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Force  XXI  Objectives  (3) 
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To  increase  tailorability  and  modularity. 

To  maximize  doctrinal  flexibility. 

»  To  maximize  different  ways  to  conduct  operations. 
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simultaneously  at  all  levels. 

-  To  increase  emphasis  on  simultaneous  strikes 
throughout  the  battlespace. 
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To  increase  anticipation  of  possible 
commitments. 


Reasons  for  an  Objectives  Tree 
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It  reveals  hidden  agendas  and  priorities  of 
important  stakeholders. 

Rationalizes  means  to  ends. 


Five  Tests  of  Logic 
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Source:  Adapted  from  Sage,  Systems  Engineering,  1992,  p.  286. 


Force  XXI  Success  Criteria 


<r% 


J2  a> 

os; 

a>  _j 

c 


3  O 

zo 


JgO 

CD  ® 

£  -Q 
<  £ 

St 

§3 

5  o.'cr 

3  w  5 
=  a>  o 

(0  a  o 
>.00  £ 
I0o 

<0  £  c 
CD  k-  -- 


o 

a>  o)  55 
-a  s  -5 

E  2  « 

3  £  J3 
Z  I-  < 


Time  Elapsed  From  Development  of  Situation 
to  Recognition  of  Situation  (Minutes) 
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More  Bounding  (1) 
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Causes  change  over  time  in  a  system,  process,  or 
operation. 


More  Bounding  (2) 
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Force  XXI  Terms 
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Intelligence 

Mobility  and  Survivability 
Combat  Service  Support 


More  Force  XXI  Terms 
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Sustained  Operations  or  Recovery 


Force  XXI  Architecture 
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Force  XXI  Technology  (1) 
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Information  technology  is  the  application  of 
scientific  knowledge  to  help  people  work  with 
data,  information,  and  knowledge. 


Force  XXI  Technology  (2) 


<D 

C 

<D  -2 
0) 


0)  o>|  > 

■-  C  O  JO 

>‘E  =  5 
O)  =  c  «- 
o  5  (0  c 

o  H  o  © 
C  c  >  © 

o  2> 


d> 


>■5 


*Jr  O  ■o 
O  CO  c 

”  CD  fl)  <0 

c  -°  £  5 
a>  S  ..  © 
hS->c 
^  o>  > 

w  ©~  £ 

o  ©  ©  ~  o 

i!2|  © 

<(/)£.= 


as 

3 

c3 


o 

c 

as 

E 

3 

sz 

a> 

E 

o 

</> 

0) 

“O 

£ 

<j> 

>< 

a> 

> 

u> 

o 


o 

a> 


as 

0) 

a> 

a 

o 


l—  a. 


Force  XXI  Technology  (3) 

Systems  life-cycle  for  technology 
identification,  assessment,  and  preliminary 
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525-5  and  AWEs  Crosswalk 
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Future  Work 
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F.  1/5 


kz 


26  Oct  94 


LTC  Armstrong: 

1.  These  are  the  charts  created  from  your  input  to  COL  Klevecz. 
He  was  very  appreciative  of  your  help. 

2.  The  Army  Science  Board  Battle  Lab  Issue  Group  will  be  here  at 
Ft.  Monroe  on  16  Nov  to  meet  with  MG  Lehowicz,  COL  Hubbard  and 
the  Early  Entry  BL,  17  Nov  I'll  take  them  to  Ft  Lee  for  an 
office  call  with  MG  Robison  and  to  meet  with  the  CSS  BL. 

If  your  schedule  allows,  would  like  for  you  to  be  here  on  the 
16th  to  discuss  your  work  on  525-5  with  them.  Don't  know  yet 
whether  Mr.  Strassman  will  be  able  to  make  it.  Will  let  you 
know. 

3.  Just  learned  last  nite  that  I'm  going  to  an  AMC  DIS  Advisory 
Group  meeting  at  Ft  Monmouth  tomorrow.  I  fly  to  Newark  this 
evening.  Had  I  known  earlier,  I  might  have  been  able  to  leave 
this  morning  and  possibly  met  with  you  today. 


Diane  Schuetze 
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Appendix  L 

Task  Force  Ranger  Cadet  Worksheets 
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^^|4^pi|igi|| 

K:~:  •H-5t'a®^^pg5i#5?>5iS5^^;:SS¥^eiim'3^«i5 '»  ?: firm'd  L-ecihsb  *4. a » hn ; sw: ?.«•  ,4 orTjiy^'^^lt^i!-^^ *•' 

fV*  Names ^  3lJST£ucroe.S  :  .....  ,  .Section 

:  .y  5o^f<  ^Ahersi.  ^  .  *  \  ,-v  .  .  ..  .  '-...  1 

:  ^  Or'‘3»‘Vf  v  •;-**  ~—  f.*v‘*  “*■  V  '  \  ■  *  '•  -v  r  ^  ^  -1  .  -»  \ 

i  /■  .  -.  :  -  •  •  >.,  w"  -**  *\‘v'  Vv»  ■^.;-v,; 


PARTI 


1.  (2  points)  Considering  that  a  system  is  a  group  of  elements  that  work  together  for  a  specified  purpose, 

identify  the  system  under  consideration.?  v\  |  .  \  ^  “  : 

Igtk  '"£a*&€x  fe&u&sr 

2.  Considering  the  "Systems  Point  of  View,”  answer  the  follow'ing: 

*.V  W  i3  *  *  .  .,  -  .1  ■„  «i  V-  4.-^  /.  T  S-  ;  -V ^  . 

*  *•  -  •  -o - V  •  T  .  •  ^  t  .  i  .*r  -  ‘  ' 

-\,  ;  '  (a)  (2  points)  .What  is  the  purpose  of  the  system  identified  above?  • 

fo  4tce*tfii*k  dsifjitfef  spcctat  *<r/iMty  operation*  wiss/ohS  £C4ecr$5/tt(/y\ 


"'  '  ‘  '  ‘(b)"  (2  points)  To  achieve  the  purpose  of  the  system,  a  number  of  functions  must  be 

implemented.  These  functions,  or  purposeful  actions,  are  basic  characteristics  of  the  system.  Identify  iwfi 
major  functions  that  will  achieve  the  purpose  of  the  system  identified  above. 


PltlAlfil  *ta 

^kHh  "  V  v  ■  .  .. ' 

(pH  (It  ($C4 

(c)  (3  points)  Considering  the  functions  you  identified  in  (2)  above,  list  only  three  operating 
components  of  the  system.  Why  are  they  operating  components?  ,  -  ,  ......  : 

Leader,  r  +U  plans t  M,\ 


Soldiers  —  "they  -exccutfe  tb-e.  j>l*HSj  d°  ^ 

Support  £Un —  They  support  fratm *$  and (r^dtueby 

(d)  (3  points)  Considering  the  functions  you  identified  in  (2)  abo\4,  list  only  lhr££  flow  P/C>1 
iponents  of  the  system.  Why  are  they  flow  components?  . " .  '  ft  C^* 

p-cople.  -  6c  'llji&f**' h&s'fy1* 

a^ea/f^Ms  UAt*  dfrddMoi*  <h*y(s  *** 


■Lr^Uh**<j, 

in  (2)  above,  list  only  three  structural  ^ 


a*e  CiU  -forms  *od'(i\'-faru**>{iou\  . 

C.Hc**y  €p(d !*•*.*  —  Arc  pMCL<L<ict .or  c*tpdutr$d* 

/  (e)  (3  points)  Considering the/functions  yon  identified 

components  of  the  system.  Why  are  they  structural  components?  _  ,/  *  .  / 

£a«-n  o-fco*^  % 

MTo£  (Unit  fyufpUAXjd-)  .  y  :  J -t^Se  do  ^cka^tukcU. 

Unit  SOp  Csta^dayd  &pcr*chLi  ftocedarcL) 


m 


9* 


Page  1  of  6 


•  :  Vr ' V’^  VA  • 

.:  .  ..  •.';•-  :  ^ ■  -7. -■■  *  Vf-  .IV.  £:=:??■  ; 


43  V 
'  DE  Lab  #1 


9 5 X S*V _-•-  -~-  - ‘ v  •••  j  .<*Tt‘V'  t  -»~s~r/S. *<-’>.<  ~»  **-. » 


super-system  of  the  system  you  identified?  Why?  -_ 


TV 


S/icci*/  ^  A ^ ^  ^ t : 

~0 f~7ts f'-fet^rfewj'er  TV“:  . :.  —  ------ 

(g)  (2  points)  What  is  a  lateral  system  of  the  system  you  identified?  Why?  ^  . 

fyc/'fa  {~oV*CG*  7 ^Crue.M'  ClftKCtSicU.  /A<  ^OiMers  * 

■  ■■:■'.•  J  Tr>>i^  A  /^*r.v 

CM  (3  points')  What  are  three  subsystems  of  the  system  you .identified?  Why?  ^  _  .. 

SI-  SuUyihu*  -  C*r<*^rrfa'™^C#t^is. 

. .  ■  52.-  **. 4rz&r* 

£z-  <2WV  Subsyth^  -ft*  W^,  ,  V  ^  /• 

■  SH  -  Suf/o/y  Mytl*.  T,'U<.  fifth*. 


^&ir.  * 


•4*.:  - 


4C 


3.  (3  points)  Identify  the  primitive  needfs)  and  state  it  in  clear  and  concise  words  below.  .Cite  the  source  of 
your  primitive  need. 

n  .  '■■  }■  .-'.- 

-  Cos  ■•_* .  .': 


(?.?■■■ 


%ec!-c$t^  *  A*-  fathers 

*  g«-c£-U»  At  fotHger*  " 

*  '*.  \  *  *  >,  \  *\  . 

.  '  ■  "  -  s\  X>.  Vv  K*\  V  -  ■>  -  >.  — -  t*  -  _V  ;.  ».  ►  -  * 

5  f  #  1  i  r.  7  •.: . 


i ;  « *  >  V  t  /  x  x 


/  . 


C«yA -Up  fw  A  TccMHo(o<jLj  ", 

4.  (5  points),.- List  at  least  five  stakeholder^  below:’ ’ 


Ho/oV-  ”  -  *V.n  vjk 


A 

vi-J' 


,.VVW  -  * 


'*V'Y-%  A '  **  *  -  -St  eh  £  Idffis  \  .  ;>  .-.i.tuvrs  *>  v^^c4\  ■**■:  -v**-2 

%  \  /  >. :  1  '  '  '  \;  *■■  ‘  V- '  ■  ^  v  '  V*'  V'  -  ,  .  ■'  ' 

Prtsi  cleM  /  \&J.f -  v.  ,,..  ,;v  ,  .,,.  VVi  «k;..  r,.... 

■  '.  '^epwftf  jOlil€p  op  ‘d’fa'frf  Prf  OptfQrftfrtS'  ■  ^ 

V1'-^  SrT^A'- 

a"  ‘ v '' £-e*t H&hfel  -  •.  *  -  >v  -  ^ 

f  ■  r  ”**  (J  ^  v  •  \ :.  -~r  ;  iV*  .  ,*  ..  x  .  ;.>?  V  i-  —  iO-  V .  r;!)  ^*:  -V;  i 

Cffb^tcss  "  .  '  ?  y': 

Sot  elites 

^M<nUU^ . .. g?^c/  ntortZl  ~ 
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TURN  IN  BOTH  PART  I  AND  PART  II  AT  THE  BEGINNING  OF LESSON 1 0.  :;J;7  V  Tbtrr^i 
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6.  (7  points)  Generalize  the  primitive  need  into  an  effective  needfs)  by  considering  the  stakeholders.  State 
the  effective  need  below  clearly  and  concisely,  ensure  vou  cite  specific  evidence  to  support  your  statement. 
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7.  (10  points)  The  stakeholders  would  like  to  achieve  many  objectives  to  support  and  satisfy  their  needs. 
After  considering  the  stakeholders,  list  five  major  objectives  that  will  satisfy  the  effective  need(s).- 
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8.  ( 1 5  points)  Con stru et  a  thorough  I phasejf  the  system  you^ 
identified.  ’ Place  your  Work  in  the  space  below.^Be  sure  td'explalri'the  priiressi*^,  what  is  being  >*••'*» 
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SUPER.  AMSuigeS  TO  Ti o\.m  QUBTIoMS 

(5  points)  The  Chief  of  Staff  has  to  testify  before  Congress  about  this  issue.  Based  on  your  design  work 
this  noint.  what  assessment  could  you  give  to  DCSOPS?  (at  this  point,  “What  is  the  Bottom  Line?  ) 
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Appendix  M 

Tutorial  on  Building  IDEFO  Activity  Models 

(Prepared  by  CPT  Jeff  Joles,  edited  by  LTC  J.  E.  Armstrong,  D/SE,  USMA,  West  Point,  NY) 
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TITLE:  Synthesis  of  Alternatives  -  Reengineering  Processes 

LESSON  OBJECTIVES: 

1.  Understand  what  reengineering  is  and  why  it  is  important  to  systems  engineers. 

2.  Understand  the  fundamentals  of  IDEFO  as  a  modeling  technique. 

3.  Describe  the  essential  components  and  structure  of  an  IDEFO  model,  to  include  context 
diagrams,  node  tree  diagrams,  and  decomposition  diagrams. 

4.  Understand  the  use  of  ICOMs  to  define  relationships  between  activities. 

5.  Model  a  process  using  IDEFO  methodology. 

STUDY  ASSIGNMENT: 

READ:  Course  Notes,  pages  1-3  through  1-8 

DRILL  PROBLEMS: 

1.  Define  the  terms:  Activity,  Input,  Output,  Control,  Mechanism  as  they  apply  to  IDEFO 
models  and  give  an  example  of  each. 

2.  Given  the  activity  and  ICOMs  below,  build  an  appropriate  IDEFO  context  diagram.  You 
may  add  additional  ICOMs  if  desired. 

Activity:  Conduct  a  Needs  Analysis 


AO 


ICOMs: 

Information 
Analyst 
Objectivity 
Top-Level  Objectives 


Environment 
Primitive  Need 
Effective  Need 
Stakeholders  (Objectives) 
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3.  Given  the  following  node  tree,  develop  an  IDEFO  decomposition  diagram  for  the  activity, 
(AO)  Sell  Pizza,  using  the  seller’s  perspective.  Include  and  label  appropriate  ICOMs. 

(AO)  Sell  Pizza 

(Al)  Enter  Order 

(All)  Accept  Order  Information 

(A  12)  Compute  and  Quote  Price 

(A  1 3)  Generate  Order  Form 

(A2)  Process  Order 

(A21)  Assemble  Pizza 

(A22)  Cook  Pizza 

(A23)  Package  Cooked  Pizza 

(A3)  Deliver  Pizza  , 

(A31)  Delivery  Person  Takes  Pizza 
(A32)  Transport  Pizza  to  Customer 
(A33)  Document  Delivery 

4.  Consider  the  process  of  writing  a  research  paper  on  an  assigned  topic.  Using  the  cadet 
perspective,  develop  an  IDEFO  context  diagram  for  the  process  and  prepare  a 
decomposition  diagram  for  the  top  level  activity.  Include  and  label  appropriate  ICOMs. 
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SYNTHESIS  OF  ALTERNATIVES 
REENGINEERING  PROCESSES 


WHAT  IS  REENGINEERING? 

In  recent  years,  reengineering  has  been  a  “buzzword”  in  the  business  community.  It  has  been 
touted  as  a  method  of  revitalizing  US  industries  that  are  in  financial  difficulty,  as  a  technique 
that  can  be  used  to  improve  the  efficiency  of  an  organization,  and  as  a  way  for  a  firm  to 
lower  costs  or  raise  productivity.  It  is  important  for  systems  engineers  to  have  an 
understanding  of  what  reengineering  is  and  how  it  is  accomplished-because  the  concept 
allows  a  reengineering  team  to  evaluate  an  existing  process  and  search  for  ways  to 
restructure  it  and  significantly  improve  mission  performance.  As  systems  engineers,  you  will 
be  called  upon  to  evaluate  existing  processes  and  make  recommendations  for  improvement. 
The  concept  of  reengineering  will  help  you  perform  this  analysis. 

So,  what  exactly  is  reengineering?  One  useful  definition  is:  “the  fundamental  rethinking  and 
radical  redesign  of  business  processes  to  achieve  dramatic  improvements  in  critical, 
contemporary  measures  of  performance  such  as  cost,  quality,  service,  and  speed.”  [1] 

Applied  in  a  broader  perspective,  during  reengineering  an  organization  undergoes  some 
detailed  introspection,  evaluates  what  its  objectives  are,  performs  a  functional  decomposition 
of  its  activities,  and  determines  what  needs  to  be  done  in  order  to  best  meet  the 
organization’s  objectives.  In  effect,  the  organization  is  redesigned  from  the  ground  up.  The 
current  reengineering  of  U.S.  Army  Forces  Command  (FORSCOM)  to  meet  the  challenges 
of  the  21st  century  is  a  good  example.  Posturing  FORSCOM  to  support  Force  XXI,  the 
Army  of  the  21st  century,  has  entailed  an  in-depth  look  at  what  FORSCOM  does  and  how  it 
accomplishes  its  mission.  The  result  of  this  massive  undertaking  has  been  new  ways  of  doing 
the  business  of  keeping  a  power-projection  Army  trained  and  ready  in  a  shrinking  resource 
environment.  [2] 

Reengineering  efforts  parallel  the  systems  engineering  design  process,  except  that  it  is  now 
being  used  to  improve  an  existing  system,  rather  than  design  a  new  one.  One  useful 
technique  when  reengineering  processes  (or  developing  new  ones)  is  function  modeling 
because  it  not  only  identifies  key  activities  (functions),  but  also  establishes  relationships 
between  activities.  A  well  constructed  function  model  is  critical  to  integrated  systems 
planning/design  since  all  components  and  relationships  are  shown.  IDEF,  short  for 
Integrated  Definition.  [3]  is  a  function  model  paradigm  sometimes  used  in  reengineering  and 
design  activities. 
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IDEF 

In  the  1970’s,  the  United  States  Air  Force  recognized  the  need  for  a  function  modeling 
methodology  as  a  result  of  the  Integrated  Computer  Aided  Manufacturing  (ICAM)  program. 
One  of  the  original  IDEF  (ICAM  DEFinition)  methods  was  IDEFO  (pronounced  Eye-DEF 
Zero).  IDEFO  is  a  static  modeling  paradigm  that  depicts  a  system  as  a  network  of 
interconnected  activities  performing  controlled  transformation  of  inputs  into  outputs  using 
mechanisms.  Additional  IDEF  models  have  since  evolved  to  meet  other  business  needs, 
including  IDEF1,  IDEF1X,  IDEF2,  IDEF  3,  and  IDEF4.  [4]  For  simple  systems,  all  the 
analyst  needs  to  build  an  IDEFO  model  is  a  stubby  pencil  and  some  paper.  Computer 
applications  are  generally  needed  to  build  more  complex  models. 

d 

REENGINEERING  AND  IDEFO  [5] 

IDEFO  methodology  allows  the  systems  engineer  to  model  the  decisions,  actions,  and 
activities  of  a  system  or  organization.  It  is  another  analysis  technique  for  establishing  the 
scope  of  analysis  and  determining  which  functions  in  a  system  are  performed  well,  and  those 
which  should  be  improved.  In  organizing  the  analysis  of  a  system,  effective  IDEFO  models 
promote  good  communications  about  the  functional  perspective  of  the  system  between  the 
analyst  and  the  client.  Because  of  this  analyst-client  link,  IDEFO  models  are  often  created 
early  in  the  systems  analysis  process. 

Using  IDEFO,  activities  can  be  organized  and  the  relation  between  activities  graphically 
represented.  Activities  are  described  by  their  inputs,  outputs,  controls,  and  mechanisms. 
Each  activity  can  also  be  decomposed  to  provide  greater  activity  detail  until  the  model  is  as 
descriptive  as  needed. 

The  hierarchical  nature  of  IDEFO  allows  the  analyst  to  construct  models  of  existing  systems 
(AS-IS  models)  which  have  a  top-down  representation  and  interpretation  but  which  are 
based  on  a  bottom-up  analysis  process.  Beginning  with  raw  system  data  (generally  obtained 
through  client  interviews),  activities  that  are  closely  related  or  similar  in  function  are  grouped 
together.  The  system  hierarchy  emerges  through  this  grouping  process  which  can  be  applied 
until  the  highest-level  activity  has  been  described.  If  a  system’s  functional  architecture  is 
being  designed  (TO-BE  modeling),  top-down  construction  is  normally  used.  Beginning  with 
the  top-most  activity,  the  system  under  design  is  described  using  functional  decomposition 
until  the  desired  level  of  detail  is  achieved. 

IDEFO  COMPONENTS  AND  STRUCTURE 

The  IDEFO  model  describes  a  system  by  its  functions  or  activities.  Activities  are  functions, 
processes,  or  tasks  that  use  mechanisms  to  transform  inputs  into  outputs  as  directed  by 
controls.  Inputs,  Controls,  Outputs,  and  Mechanisms  are  referred  to  as  ICOM s. 
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ICOMs  [6] 

Input  -  something  that  is  transformed  by  an  activity.  Some  examples  of  inputs  are  raw 
materials,  information,  client  need,  etc.  Inputs  are  represented  by  an  arrow  entering  the 
activity  box  from  the  left 

Control  -  something  that  determines  how  or  when  an  activity  occurs,  but  is  not  transformed 
by  it.  Examples  of  controls  include  regulations,  policies,  objectives,  etc.  Controls  are 
represented  by  an  arrow  entering  the  activity  box  from  the  top. 

Output  -  something  that  is  produced  by  or  results  from  an  activity.  Examples  of  outputs  are 
products,  data,  transformed  materials,  etc.  Outputs  must  include  tiie  input  in  some  fonn. 
Outputs  are  represented  by  an  arrow  exiting  the  activity  box  from  the  right. 

Mechanism  -  resources  (people,  facilities,  machines,  systems)  that  provide  energy  to  or 
perform  the  activity.  Some  examples  of  mechanisms  are  equipment,  an  analyst,  computer 
system,  etc.  Mechanisms  are  represented  by  an  arrow  entering  the  activity  box  from  the 
bottom. 

The  IDEFO  model  represents  a  system  as  activities  that  use  ICOMs  to  accomplish  tasks. 
When  an  activity  uses  an  ICOM,  the  IDEFO  model  shows  the  use  by  attaching  the  ICOM’s 
arrow  to  the  affected  activity  box  as  depicted  in  the  basic  IDEF  model  in  Figure  1 1-1.  An 
activity  box  may  have  any  number  of  ICOMs  of  any  type. 


_ 3 

Control  ICOM(s) 

i _ 

Input  ICOM(s) 

Activity  Box 

AO 

Output  ICOM(s) 

2 

c 

Mechanism  ICOM(s) 

Figure  1-1.  Basic  IDEF  Model. 
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Labels 

In  addition  to  identifying  an  ICOM  by  its  position  relative  to  the  activity  box,  each  ICOM 
arrow  must  have  a  label  to  identify  what  it  is.  The  following  rules  apply  to  IDEF  labeling  of 
activities  and  ICOMs. 

Activities  are  ALWAYS  labeled  with  a  verb  or  verb  phrase;  conduct  analysis,  plan 
party,  manufacture  part,  etc. 

ICOMs  are  ALWAYS  labeled  with  a  noun  or  noun  phrase. 

For  example,  the  IDEFO  context  diagram  for  Figure  11-1  might  look  like  this  for  the  activity. 
Fire  M-16. 


j  Rules  of  Engagement 

Target _ 

Ammunition 

Weapon  (M-16) 

Soldier 


‘Bulls-eye’ 

- ► 


Figure  1-2.  Context  Diagram,  Fire  M-16. 


Context  Diagrams 

A  context  diagram  is  the  single  IDEFO  activity  representing  the  system  and  its  interface  with 
the  outside  world.  This  diagram  shows  the  context  within  which  the  model  exists  and 
includes  only  those  features  relevant  to  the  model’s  purpose.  Figure  1 1-2  is  one  possible 
context  diagram  for  the  activity.  Fire  M-16.  Note  that  the  activity  box  is  labeled  AO 
indicating  that  it  is  the  context  diagram  in  the  model’s  hierarchical  structure. 
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Node  Tree  Diagrams 

Similar  to  objective  or  criteria  diagrams,  node  trees  are  useful  for  defining  large  complex 
models  without  ICOMs.  Each  node  of  the  tree  is  a  function  or  activity  whose  node  number 
corresponds  to  an  activity  box  in  the  IDEFO  model’s  hierarchy.  Similar  to  the  outline  used 
by  a  writer,  node  trees  are  often  useful  in  outlining  the  system  before  developing  an  IDEF 
model. 

A  node  tree  for  the  context  diagram  in  Figure  1 1-2  might  look  like  the  representation  below 
where  the  designations  preceding  each  activity  indicates  a  node.  Note  that  ICOMs  are  not 
shown  on  the  node  diagram. 

-  • 

* 

(AO)  Fire  M- 16 

(A  1 )  Prepare  to  Fire 

(All)  Assume  Position 
(A  12)  Load  Weapon 
(A2)  Acquire  Target 

(A21)  Sight  Target 
(A22)  Determine  Range 
(A3)  Squeeze  Trigger 

(A3 1 )  Steady  Weapon 
(A32)  Apply  Trigger  Pressure 

Graphically,  the  same  diagram  might  be  portrayed  as  below: 


Figure  1-3.  Node  Tree  Diagram. 
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Decomposition  Diagrams 

Activity  boxes  can  be  depicted  in  more  detailed,  lower  level  diagrams  representing  those 
activities  comprising  a  “parent”  activity.  [7]  In  Figure  1 1-3  above,  activity  A1  is  the  “parent” 
of  activities  All  and  A 12,.  Once  again  using  the  previous  node  tree  to  describe  the  activity. 
Fire  M-16,  the  decomposition  of  the  context  diagram  (Figure  11-2)  might  look  like 
Figure  1 1-4.  NOTE:  An  output  from  one  activity  may  become  an  input,  control,  or 
mechanism  for  another  activity.  To  highlight  the  concept  of  decomposition  diagrams,  only 
the  context  diagram’s  ICOMs  are  included  in  Figure  11-4.  Normally,  all  appropriate  ICOMs 
would  be  labeled. 
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SUMMARY 

Reengineering  is  a  fact  of  life  as  organizations  strive  to  improve  efficiency.  DDEF  functional 
modeling  is  a  useful  technique  available  to  systems  engineers  in  redesigning  existing  systems 
and  designing  new  ones. 

NOTES 

[1]  Michael  Hammer  and  James  Champy,  Reengineering  the  Corporation,  (New  York: 
1993)  32. 

-  • 

[2]  General  Dennis  J.  Reimer,  “Reengineering  Forces  Command  for  the  21st  Century,” 
Army  May  1995:  31-34. 

[3]  D.  Appleton  Company,  Inc.,  Corporate  Infoimation  Management  Process  Improvement 
Methodology  for  DoD  Functional  Managers,  (Fairfax,  VA:  1993)  158. 

[4]  Knowledge  Based  Systems,  Inc.,  AI0  WIN  User’s  Manual  and  Reference  Guide, 
(College  Station,  TX:  1993)  1-6. 

[5]  Knowledge  Based  Systems,  Inc.,  1-7. 

[6]  Meta  Software  Corporation,  Design/IDEF  Tutorial  for  Microsoft  Windows, 
(Cambridge,  MA:  1995)  4-3  to  4-5. 

[7]  Meta  Software  Corporation,  4-10. 
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Enterprise  Modeling.  Eclectic  Solutions,  San  Diego  CA,  1993. 
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Lesson  Title:  Synthesis  of  Alternatives:  Activity  Modeling 
Lesson  Objectives: 

1.  Apply  Activity  Based  Costing  (ABC)  to  an  IDEF  model  and  determine  the 
value  added  for  specific  activities. 

2.  Given  an  IDEF  activity  model,  create  reengineering  alternatives. 

k 

Study  Assignment: 

* 

Read:  Course  Notes,  pages  2-5  through  2-14. 

Read:  Supplemental  Reading,  Extract  from  Reengineering  the  Corporation  by 
Michael  Hammer  and  James  Champy. 

Drill  Problems: 

1.  You  are  the  owner  of  a  small  pizza  shop.  As  part  of  a  business  analysis,  you 
perform  an  IDEF  decomposition  of  the  activity  “Sell  Pizza”.  Now  you  want  to 
apply  ABC  to  determine  all  of  your  activity  costs.  Fill  in  the  missing  activity  based 
costs  in  the  IDEF  model  on  the  following  four  pages.  What  is  the  cost  of  the  AO 
activity  “Sell  Pizza”? 

Note:  You  have  determined  that  to  “assemble  pizza”  costs  you: 

Direct  Labor:  $0.70 
Indirect  Labor:  $0.35 
Cost  of  Goods:  $2.10 
Supplies:  $0.20 
Overhead:  $0.30 

2.  Think  of  a  system  that  you  consider  broken;  one  that  is  not  meeting  customer 
needs.  Describe,  in  the  terms  of  this  lesson,  what  problems  there  are  with  the 
system.  How  might  you  apply  reengineering  techniques  to  the  system  in  order  to 
improve  it? 


2-1 

Synthesis  of  Alternatives:  Activity  Modeling 


SE  401 
AT  962 


Introduction  to  Systems  Design 


Lesson  2 


2-2 

Synthesis  of  Alternatives:  Activity  Modeling 


SE  401  Introduction  to  Systems  Design  Lesson  2 

AT  962 

Drill  Problem#! (continued): 


USED  AT: 

AUTHOR:  USMACadet 

DATE  04/23/95 

X 

WORKING 

READER 

DATE 

CONTEXT: 

SE  401 

PROJECT:  Pizza  Shop 

REV:  1 

DRAFT 

NOTES:  1  2  3  4  5  6  7  8  9  10 

RECOMMENDED 

■ 

PUBLICATION 
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Drill  Problem  #1  (continued): 
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Activity  Modeling 

In  the  last  lesson,  you  learned  about  DDEF  activity  modeling  and  how  it  can  be 
used  to  display  the  decomposition  of  a  system.  These  IDEF  diagrams  are  natural  starting 
points  for  reengineering  existing  processes.  By  evaluating  the  current  structure  of  a 
system’s  activities  and  then  asking,  “How  would  I  accomplish  these  objectives  if  I  were 
designing  the  system  from  scratch?”,  the  analyst  can  compare  the  as-is  and  the  to-be 

models  and  identify  areas  where  there  are  significant  opportunities  for  process 

* 

improvement. 

Activity  Based  Costing 

Activity  based  costing  (ABC)  is  one  method  that  you  can  use  to  help  determine  the 
relative  value  added  by  each  activity  in  a  system.  It  is  a  technique  that  measures  the  cost 
and  performance  of  activities.  [1]  This  allows  the  analyst  to  identify  activities  that  add 
little  or  no  value  to  the  system,  and  in  turn  to  consider  eliminating  or  reengineering  the 
processes  of  which  these  activities  are  part. 

The  goal  of  ABC  is  to  pinpoint  where  resources  are  being  expended  in  a  system 
and  to  identify  what  is  being  gained  through  these  expenditures.  A  typical  system  has 
many  activities,  and  each  activity  requires  some  type  of  resource(s)  such  as  computer  time, 
money,  material,  manpower,  or  machinery.  The  first  step  of  ABC  is  to  determine  the  cost 
of  each  activity.  This  is  typically  done  by  examining  historical  financial  records,  talking  to 
the  people  involved  in  the  process,  and  sometimes  by  actually  observing  the  activity  while 
it  is  being  performed.  Costs  are  usually  expressed  in  dollars  per  unit  of  output  for  an 
activity.  The  components  which  comprise  an  activity's  costs  could  be  broken  down  in 
many  ways.  One  method  is  to  classify  the  costs  as:  [2] 

1 .  Direct  Labor:  The  labor  costs  for  the  workers  who  actually  perform  the 
activity.  For  example,  if  the  activity  is  “Type  Requisition”  and  a  clerk  who  is 
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paid  $8.00  per  hour  takes  an  average  of  15  minutes  to  type  it  up,  then  the 
direct  labor  cost  is  $2.00. 

2.  Indirect  Labor:  A  proportional  share  of  all  non-direct  labor  costs  that  can  not 
be  directly  associated  with  specific  activities.  For  example,  the  labor  costs  of 
supervisors,  janitors,  or  security  personnel.  The  “Type  Requisition”  activity 
might  be  allocated  $0.50  in  indirect  labor  costs  each  time  it  is  performed. 
Managers  and  the  accounting  staff  will  determine  how  the  overall  indirect  labor 
cost  will  be  applied  to  each  activity  in  the  system. 

-  ■» 

* 

3.  Direct  Materials  or  Cost  of  Goods:  The  cost  of  the  materials  used  to  perform 
a  specific  activity.  For  example,  the  “Type  Requisition”  activity  might  have  a 
direct  material  cost  of  $0.20  to  cover  the  cost  of  the  form  being  processed. 

For  a  construction  activity  like  “Pour  Basement”,  direct  material  costs  would 
include  the  price  of  the  concrete  and  the  steel  reinforcement  rod. 

4.  Supplies:  The  cost  of  inexpensive,  common  items  used  in  the  performance  of 
an  activity.  For  example,  the  cost  of  glue,  nails,  or  paper  required  by  multiple 
activities  are  often  classified  as  supply  costs. 

5.  Overhead:  A  proportional  share  of  all  the  other  system  costs.  This  may 
include  items  such  as  utility  costs,  taxes,  depreciation,  repairs,  and  insurance. 
Like  indirect  labor,  a  certain  proportion  of  the  overall  overhead  cost  will  be 
allocated  to  each  activity. 

The  IDEF  model  makes  the  calculation  of  activity  costs  easy.  The  costs  for  the 
lowest  level  activities  are  calculated  first,  using  the  criteria  listed  above.  These  costs  are 
then  “rolled-up”  to  determine  the  cost  of  the  next  higher  level  activity  of  which  they  are 
sub-components.  Suppose,  for  example,  our  activity  is  Write  SE  401  Report.  The 
necessary  sub-activities  are  Do  Research,  Write  Document,  and  Print  Results,  which  have 
activity  costs  of  $34.85,  $85.80,  and  $9.55  respectively.  Then  the  activity  cost  for 
Assemble  Student  Handouts  is  $130.20,  the  sum  of  the  three  sub-activity  costs.  Note  that 
the  costs  are  typically  recorded  in  the  lower  left  corner  of  each  activity  box. 
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Note:  For  the  sake  of  clarity,  most  EDEF 


Once  all  the  ABC  costs  have  been  determined,  you  can  focus  in  on  reengineering 
opportunities.  The  key  is  to  identify  activities  that  cost  a  lot,  yet  have  little  or  no  value- 
added.  Starting  at  the  top  of  the  IDEF  model,  ask  “Which  activities  could  be  eliminated 
or  reduced  without  causing  any  deterioration  to  the  product  or  service  that  the  system  is 
designed  to  provide?”  Or,  equivalently,  we  could  ask,  “Which  activities  in  the  model  do 
not  support  any  of  our  system  objectives?”  In  particular,  focus  on  activities  that  have 
relatively  high  costs.  The  non-value  adding  activities  identified  through  this  process  are 
typically  those  which  have  been  added  to  the  system  due  to  non-conformance  to  standards 
or  policies,  or  ones  that  have  been  used  to  correct  some  form  of  system  deficiency.  Non¬ 
value  adding  activities  lead  to  non-value  adding  costs.  They  waste  time,  money,  and  other 
system  resources.  They  also  unnecessarily  complicate  the  overall  system. 

An  activity’s  “value-added”  is  the  difference  between  the  value  associated  with 
that  activity’s  output  and  the  sum  of  the  values  of  the  input,  controls  and  mechanisms  that 
feed  into  it.  As  an  equation: 

Vi  =  Oj  -  [Ij  +  Q  +  Mi] 

where: 

Vj  is  the  value-added  for  activity  i 

Oj  is  the  value  of  the  output  of  activity  i 

Ii  is  the  value  of  the  inputs  coming  into  activity  i 
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Q  is  the  value  of  the  activity’s  controls 

Mj  is  the  value  of  the  mechanisms  that  are  used  by  the  activity. 

One  way  to  quantify  the  value  of  the  input,  controls,  and  mechanisms  of  an  activity  is  to 
determine  what  they  cost  per  unit  of  output  for  that  activity.  For  example,  say  that  a 
particular  cadet  assesses  the  value  of  a  finished  SE  401  report  at  $150.  (That  figure  is 
obviously  too  low,  but  it  will  illustrate  the  point.)  If  we  have  determined  that  the  value  of 
the  report  before  it  is  printed  is  $140  and  that  the  cost  of  the  controls  and  mechanisms 
required  to  “Print  Results”  are  $1.10  and  $8.45  respectively,  then  the  value  added  for 
“Print  Results”  is: 

V Prim  Report  =  $  1 50  -  [$  1 40  +  $  1 . 10  +  $8.45] 

=  $0.45 

We  would  conclude  that  the  “Print  Report”  activity  adds  $0.45  in  value  to  the  process. 

We  should  note  at  this  point  that  determining  the  input  and  output  values  for  each 
activity  is  usually  not  an  easy  thing  to  do.  It  is  hard  to  quantify  what  the  output  value  of 
the  “Do  Research”  activity  is  when  we  are  writing  an  SE  401  report.  One  way  to 
approach  this  is  by  first  determining  the  value  of  the  final  system  output  (what  a  typical 
customer  would  be  willing  to  pay),  and  then  examining  each  activity  in  an  attempt  to 
determine  how  much  it  contributes  to  that  final  value.  This  is  best  done  by  working 
closely  with  people  who  have  a  very  good  understanding  of  the  process,  allowing  them  to 
determine  the  relative  importance  of  the  individual  activities.  Some  iteration  and 
adjustment  will  usually  be  necessary,  since  the  value  of  an  activity  will  be  assessed 
differently  by  people  with  varying  perspectives  on  the  system. 

If,  for  example,  we  have  come  to  a  consensus  among  SE  401  students  that  the  final 
value  of  a  completed  SE  401  report  is  $150,  we  might  assign  the  costs  in  proportion  to  the 
amount  of  effort  required  by  each  of  the  sub-activities  and  come  up  with  $60  as  the  value 
of  “Do  Research”,  $80  as  the  value  of  “Write  Document”,  and  $10  as  the  value  of  “Print 
Results”.  As  shown  below,  we  can  apply  the  value-added  equation  to  these  figures  and 
determine  how  much  value  each  of  the  activities  add  to  the  process.  Note  that  whenever 
the  combined  input,  control,  and  mechanism  costs  for  an  activity  are  greater  than  the 
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output  value,  we  will  have  a  negative  value-added  for  that  activity.  Put  simply,  the 
activity  is  costing  more  than  its  output  is  worth,  and  such  activities  are  ideal  candidates  for 
elimination  or  modification. 

Suppose  that  the  costs  and  input/output  values  are: 


Input  Value 

s/ 


Control  Costs 

$9.40 

$30.50 

$1.10 

Output  Value 

* 

j: - .  /  - ! 

r  ^ 

r 

Write 

*|  Document 
A22| 


$140 


|  Print  Results 
A23 


$150 


it  . . 

k  4 

[ - 

$25.45 

$55.30 

$8.45 

Mechanism  Costs 

Then  to  calculate  the  value-added  for  activity  A21  we  have: 

Va21  -  Oa21  -  [Ia21  +  Ca21  +  Ma2i] 

=  $60-  [$0  +  $9.40  +  $25.41  ] 

=  $60  -  $34.85 
=  $25.15 

We  are  now  ready  to  search  for  activities  which  could  be  improved  through 
reengineering.  To  do  this,  we  want  to  identify  costs  and  values  that  are  “out  of  line”  by 
creating  a  table  which  compares  the  relative  proportion  of  cost  and  value-added  associated 
with  each  activity.  Be  careful  to  only  compare  activities  that  are  on  the  same  level  of  the 
EDEF  diagram.  For  example,  it  is  appropriate  to  compare  the  costs  of  the  Al,  A2,  and  A3 
activities,  but  it  is  incorrect  to  compare  costs  associated  with  the  Al  and  A22  activities 
because  the  A22  activity  is  at  a  lower  level  in  the  DDEF  decomposition  than  Al.  A  table 
that  compares  the  costs  of  the  activities  associated  with  “Write  SE  401  Report”  might 
look  like: 
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Total  Activity 


Activities 

Direct  Labor 

Indirect  Labor 

Direct  Material 

SuDDlies 

Overhead 

Activitv  Cost 

Percentaae 

Do  Research 

$22.65 

$9.00 

$1.75 

$0.35 

$1.10 

$34.85 

27% 

Write  Document 

$72.50 

$7.00 

$3.30 

$1.20 

$1.80 

$85.80 

66% 

Print  Results 

$2.40 

$0.00 

$5.10 

$1.45 

$0.60 

$9.55 

7% 

Total  Cost  of  "Write  SE  401  Report": 


$130.20 


Pareto  Cost  Analysis 


The  important  thing  to  examine  is  the  relative  costs  of  the  three  activities.  This  is  often 
called  a  Pareto  Analysis1  because  we  are  trying  to  identify  the  20  percent  of  the  activities 
that  are  causing  80%  of  our  costs.  In  this  case,  66%  of  the  student’s  cost  originates  from 
the  “Write  Document”  activity.  This  activity,  therefore,  is  a  logical  place  to  begin  looking 
for  ways  to  improve  the  “Write  SE  401  Report”  process. 

Once  the  high-cost  areas  have  been  identified  and  prioritized,  we  look  next  at  the 
value  added  by  each  of  the  activities.  In  tabular  form  we  might  have: 


Input 

Output 

Control 

Mechanism 

Value 

Percent  of  Positive 

Activities 

Value 

Value 

Costs 

Costs 

Added 

Value  Added 

Do  Research 

$0.00 

$60.00 

$9.40 

$25.45 

$25.15 

98.24% 

Write  Document 

$60.00 

$140.00 

$30.50 

$50.30 

($0.80) 

0.00% 

Print  Results 

$140.00 

$150.00 

$1.10 

$8.45 

$0.45 

1.76% 

Value-Added  Analysis 


So  based  on  these  figures,  the  vast  majority  of  the  value  is  added  in  the  “Do  Research” 
step.  The  “Write  Document”  activity,  on  the  other  hand,  has  a  negative  value-added, 
indicating  that  the  benefit  of  “Write  Document”  is  less  than  the  costs  incurred  by 
performing  the  activity. 

Finally,  we  compare  the  cost  and  value-added  of  the  activities. 


1  French  economist  Vilfredo  Pareto  studied  the  distribution  of  wealth  in  the  19th  century.  He  observed 
that  a  large  proportion  of  overall  wealth  is  consistently  owned  by  a  small  proportion  of  society.  Since 
then,  this  Pareto  Effect  has  since  been  recognized  in  many  different  systems  where  a  large  percentage  of 
the  system  resources  are  consumed  by  relatively  small  percentage  of  the  components. 
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Activity 

Activity’s  Percentage 

Activity's  Percent  of 

Activities 

Cost 

of  Total  Cost 

Positive  Value  Added 

Do  Research 

$34.85 

$25.15 

27% 

98.24% 

Write  Document 

$85.80 

($0.80) 

66% 

negative 

Print  Results 

$9.55 

$0.45 

7% 

1.76% 

Comparison  of  Activity  Costs  and  Value-Added 


We  look  for  activities  that  have  a  relatively  high  cost  and  low  value-added.  In  this 
example,  we  see  that  although  66%  of  our  costs  are  incurred  in  the  “Write  Document” 
step,  it  actually  has  negative  value-added.  This  makes  it  our  number  one  priority  for 
reengineering.  We  could  ask,  for  example,  why  the  direct  labor  costs  associated  with 
“Write  Document”  are  so  high.  Is  it  because  the  requirements  for  the  report  were  not 
clear?  Or,  perhaps  it  took  longer  than  necessary  to  write  the  document  because  the  cadet 
was  trying  to  write  the  paper  at  Grant  Hall.  We  could  then  seek  other  possible  solutions. 
For  example,  could  a  small  investment  in  additional  research  significantly  reduce  the  direct 
labor  cost  associated  with  writing  the  document?  Are  there  other  steps  we  could  take  to 
make  the  “Write  Document”  activity  less  time  intensive? 

In  summary,  we  can  generally  categorize  the  process  of  ABC  analysis  into  five 
steps.  First,  decompose  the  activities  down  to  a  level  where  you  can  pinpoint  the  specific 
costs  of  all  activities.  Second,  starting  at  the  bottom,  “roll-up”  the  costs,  aggregating  the 
costs  for  each  decomposition  up  to  the  next  higher  level.  Third,  determine  the  input  and 
output  values  for  each  activity  in  the  process.  From  this,  calculate  the  value-added  for 
each  activity.  Fourth,  create  tables  which  allow  comparison  of  the  activity  costs  and 
value-added  for  all  the  activities  at  a  particular  level  in  the  decomposition.  Identify  the 
activities  that  have  the  highest  costs.  Fifth,  and  most  importantly,  prioritize  for 
reengineering  those  activities  that  have  both  high  costs  and  low  value-added  and  seek 
creative  means  of  reducing  costs  and  adding  values. 


Indicators  of  Reengineering  Opportunities 

Activity  based  costing  is  just  one  of  several  analytic  techniques  that  you  can  apply 
to  an  IDEF  model.  As  you  evaluate  an  existing  system  model,  be  aware  that  there  are 
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other  specific  indicators  that  serve  as  red  flags  indicating  potential  reengineering 
opportunities.  These  include:  [3] 

1 .  Processes  that  are  broken.  Situations  where  the  management,  employees,  or 
customers  involved  readily  admit  that  some  of  the  system’s  objectives  are  not 
being  achieved. 

2.  Cases  of  extensive  infonnation  exchange,  data  redundancy,  and  information 
rekeving.  These  are  cases  where  information  is  being  handled  inefficiently.  This  is 
typically  due  to  an  ill-structured  organization.  For  example,  when  information 
needed  as  part  of  a  process  must  be  bounced  back  and  forth  between  two  or  more 
departments,  this  is  an  indicator  that  perhaps  the  departmental  structure  is  not 
efficient.  In  many  instances  this  is  due  to  unnatural  boundaries  within  a  system, 
boundaries  that  are  created  when  an  organizational  structure  does  not  facilitate 
accomplishment  of  the  systems  objectives. 

3.  Inventories  or  buffers.  Inventories  and  stockpiles  of  “spare”  items  are  created 
to  help  deal  with  uncertainty  in  a  system.  Often,  they  indicate  a  process  that  can 
not  quickly  respond  to  user  requirements.  By  redesigning  the  process  to 
coordinate  supplier  and  user  schedules  and  requirements,  the  inventories  may  be 
significantly  reduced  or  eliminated  entirely. 

4.  High  ratios  of  checking  and  control  to  value-adding.  The  activities  in  a  system 
must  be  focused  on  accomplishing  the  system’s  objectives.  Some  amount  of 
checking  and  control  will  almost  always  be  required  in  order  to  ensure  the  quality 
of  the  system  output.  However,  each  step  that  requires  inspection,  bookkeeping, 
and  paperwork  costs  time  and  money.  Thus,  it  is  critical  that  these  administrative 
activities  be  kept  to  a  minimum,  and  handled  efficiently  when  required. 

5.  Rework  .  Whenever  an  activity  must  be  repeated  because  it  wasn’t  done  right 
the  first  time,  that  activity  consumes  valuable  system  resources  (time,  money, 
manpower,  material,  etc.).  Often  times  rework  must  be  done  because  system 
requirements  and  specifications  are  either  unclear  or  change  over  time. 
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Reengineering  should  focus  on  eliminating  the  confusion  and  mistakes  that  lead  to 
excessive  rework. 

6.  Complexity,  exceptions,  and  special  cases.  The  longer  a  system  is  in  operation, 
the  more  complex  it  tends  to  become.  This  is  because  what  starts  out  as  a  simple 
process  is  typically  modified  and  added  to  as  time  goes  on.  Eventually,  the 
exceptions,  contingency  plans,  and  possible  alternatives  grow  to  the  point  where 
the  original  process  is  lost  in  the  background.  When  this  happens,  it  is  usually 

necessary  to  simplify  the  process,  possibly  dividing  it  into  several  smaller 

* 

streamlined  activities. 

7.  Duplication  of  activities.  When  identical  or  very  similar  activities  are  being 
performed  at  various  points  in  a  system,  it  may  be  possible  to  consolidate  some  or 
all  of  those  activities.  This  has  the  potential  to  eliminate  duplication  of  labor, 
increase  the  expertise  available  for  that  activity,  and  reduce  the  amount  of 
overhead  required. 

Automation 

Activity  modeling  can  also  assist  in  the  process  of  coherently  automating  activities 
in  a  system.  The  IDEF  model  specifically  delineates  how  information  is  passed  throughout 
the  process.  By  understanding  this  flow,  analysts  can  tailor  their  computer  systems  to 
meet  the  actual  information  exchange  and  data  processing  activities  of  the  system. 

Activity  models  are  also  used  to  create  business  rule  models  or  data  models.  A 
data  model  is  a  graphical  representation  of  an  organization’s  information  and  data 
expressed  in  terms  of  entities  and  relationships.  These  relationships  are  also  called 
business  rules  because  they  enable  or  constrain  business  actions.  This  set  of  rules  and  data 
modeling  techniques  is  called  IDEF  IX  (pronounced  eye-deaf-one-x). 

Summary 

The  IDEF  decomposition  process  is  an  activity  model  which  provides  a  detailed 
picture  of  how  all  the  activities  in  a  system  interact.  It  facilitates  the  application  of  other 
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tools  such  as  Activity  Based  Costing.  By  looking  for  key  indicators  in  the  decomposed 
processes,  the  systems  engineer  can  identify  reengineering  opportunities  and  can 
reorganize  the  activities  to  more  efficiently  meet  the  system’s  objectives. 


NOTES 

[1]  Corporate  Information  Management  Process  Improvement  Methodology  for  DoD 
Functional  Managers  (Fairfax:  D.  Appleton  Company,  Inc.,  1993)  103. 

-  » 

* 

[2]  Ray  H.  Garrison,  Managerial  Accounting  (Plano:  Business  Publications,  Inc.,  1985) 
28-29. 


[3]  Michael  Hammer  and  James  Champy,  Reengineering  the  Corporation  (New  York: 
Harper  Business,  1993)  122-127. 
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Lesson  Title:  Modeling  and  Analysis  -  Simulation  of  Activity  Models 
Lesson  Objectives: 

1.  Understand  the  usefulness  of  simulation  as  a  modeling/analysis  technique. 

2.  Understand  the  progression  from  static  to  dynamic  system  models. 

3.  Be  able  to  list  and  describe  several  simulation  techniques,  and  know  the 
advantages  and  disadvantages  of  each. 

4.  Be  able  to  use  the  fesults  of  a  simulation  to  recommend  changes  to  both  static 
and  dynamic  system  models. 

Study  Assignment: 

Read:  Course  Notes,  pages  3-2  through  3-7. 

Drill  Problems: 

None. 

Other  Requirements: 

None. 
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SIMULATION  OF  ACTIVITY  MODELS 

Introduction  to  Simulation 

This  lesson  focuses  on  another  powerful  analysis  technique  called  simulation.  As 

you  have  learned  in  previous  courses,  simulation  is  a  field  of  study  that  seeks  to  analyze 

complex  interactions  in  a  system  by  using  a  computer  to  model  how  the  system  changes 

over  time.  In  this  lesson,  we  will  learn  how  we  can  use  simulation  to  assist  us  in  the 

&  "  9 
analysis-of-altematives  step  of  the  systems  engineering  design  process. 

Modeling 

Before  we  can  understand  the  role  of  simulation  in  the  design  process,  we  need  to 
know  what  it  means  to  “model”  a  system.  Modeling  is  the  process  of  developing  a 
description  of  a  system  that  accounts  for  all  of  the  system’s  important  properties.1  That  is, 
a  model  is  an  abstraction  of  reality,  a  simplified  description  of  the  elements  and 
interactions  that  take  place  in  a  complex  system.  The  model  is  designed  to  provide  the 
analyst  with  essential  information  about  system  it  represents. 

It  is  almost  always  cheaper  and  faster  to  work  with  a  model  than  to  directly  study 
the  dynamics  of  a  large-scale  system.  In  some  cases,  such  as  when  we  are  developing  a 
new,  non-existing  system,  it  may  actually  be  impossible  to  work  with  a  real  system.  In 
these  instances,  the  analyst  is  forced  to  rely  on  models  in  order  to  perform  the  analysis.  It 
is  very  important  that  the  model  be  properly  formulated,  used,  and  interpreted  so  that  the 
results  accurately  reflect  the  characteristics  of  the  real  system. 

There  are  two  general  modeling  paradigms:  static  and  dynamic.2  A  static  model 
represents  the  structure  of  a  system,  but  does  not  show  how  the  system  changes  over  time. 
DDEFO  is  one  example  of  a  static  model  that  we  have  already  used  in  this  course.  A 
dynamic  model,  on  the  other  hand,  represents  both  the  structure  of  the  system,  and  that 
system’s  behavior  over  time.  Dynamic  models  are  generally  much  more  detailed  than 
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static  models  because  they  must  incorporate  logic  concerning  exactly  what  interactions 
take  place  within  the  model  and  how  the  system  changes  over  time.  We  will  use 
simulation  as  a  dynamic  modeling  tool  to  investigate  these  changes  in  key  system 
variables,  particularly  during  the  operational  phase  of  its  life-cycle. 

When  to  Use  Simulation 


For  very  simple  systems  it  is  sometimes  possible  to  develop  analytic  models  which 
can  be  solved  mathematically'.3  For  example,  the  M/M/1  queuing  model,  the  EOQ 
inventory  model,  and  simple  Poisson  Processes  are  all  analytic  models  you  have  used  in 
other  Systems  Engineering  courses.  To  use  these  types  of  analytic  models,  we  first  verify 
that  the  assumptions  of  the  particular  model  are  satisfied,  then  we  determine  the  required 
input  parameters,  and  finally  we  solve  for  the  particular  variable(s)  of  interest.  The 
strength  of  analytic  models  is  that  we  can  obtain  exact  solutions.  On  the  other  hand, 
analytic  models  are  usually  not  sufficient  when  we  are  designing  large-scale  systems. 
Often,  this  is  because  the  real-world  system  fails  to  satisfy  one  or  more  of  the  assumptions 
of  simple  analytic  models.  Additionally,  the  larger  and  more  complex  a  system  becomes, 
the  more  difficult  it  is  to  identify  and  quantify  interacting  variables. 

Simulation,  on  the  other  hand,  allows  us  to  develop  computer  models  of  complex 
systems,  observe  how  the  system  behaves  over  time,  and  draw  inferences  about  important 
system  variables.  This  makes  simulation  very  useful  for  the  types  of  problems  we  study  in 
this  course.  Simulation  will  not  provide  exact  solutions  to  a  particular  problem.  It  will, 
however,  allow  the  analyst  to  statistically  analyze  results  and  to  make  probabilistic 
statements  about  the  system.  For  example,  we  might  conduct  a  simulation  of  a  pizza 
restaurant  and  find  that  at  a  95%  confidence  level,  the  mean  time  it  takes  to  make  a 
pepperoni  pizza  is  between  3.5  and  3.7  minutes.  We  will  not  obtain  exact  solutions,  but 
can  obtain  approximations  to  the  necessary  level  of  precision. 
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Advantages  and  Disadvantages  of  Simulation 

Building  a  simulation  of  a  system  usually  requires  a  significant  investment  of  time 
and  effort.  The  costs  include  software,  training,  and  time.4  The  benefits,  however,  include 
an  improved  ability  to  understand  the  interactions  of  the  system.  In  the  long-run,  this 
leads  to  the  capability  to  design  a  more  appropriate,  efficient,  and  cost-effective  system. 
The  trade-offs  will  typically  look  like: 


Design  Operational 

Phase  Phase 


Cost  with  simulation  — 
Cost  without  simulation 


This  shows  that  the  additional  up-front  cost  associated  with  developing  a  simulation  can 
quickly  be  recovered  through  efficiency  and  cost  savings  in  the  operational  phase  of  the 
systems  life-cycle. 

Other  advantages  of  simulation  discussed  by  Schmidt  and  Taylor  (1970)  include:5 


1.  Once  a  model  is  built,  it  can  be  used  repeatedly  to  analyze  proposed  designs  or 
policies. 

2.  It  is  usually  the  case  that  simulation  data  is  much  less  costly  to  obtain  than 
similar  data  from  the  real  system. 

3.  Simulation  methods  are  usually  easier  to  apply  than  analytic  methods.  Thus, 
there  are  many  more  potential  users  of  simulation  methods  than  of  analytic 
techniques. 
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4.  Whereas  analytic  models  usually  require  many  simplifying  assumptions  to  make 
them  mathematically  tractable,  simulation  models  have  no  such  restrictions. 

5.  In  some  instances,  simulation  is  the  only  means  of  deriving  a  solution  to  a 
problem.  That  is,  simulation  can  be  used  in  cases  where  analytic  models  do  not 
exist. 


Schmidt  and  Taylor  also  point  out  that  there  are  several  disadvantages  to  simulation. 

These  include: 

*  " 

1 .  Simulation  models  may  be  costly,  requiring  large  expenditures  of  time  for 
construction  and  validation. 

2.  Simulation  is  sometimes  used  even  when  precise  analytic  techniques  would 
suffice. 

3.  Simulation  results  are  only  as  good  as  the  model  used  to  derive  them.  That  is, 
if  the  model  fails  to  capture  important  aspects  of  the  system,  the  results  may  be 
misleading  or  incorrect. 

Methods  of  Simulation 


There  a  several  techniques  that  can  be  used  to  simulate  a  system.  At  the  simplest 
level,  a  spreadsheet  can  be  used  to  capture  important  system  dynamics.  The  spreadsheet 
can  be  used  to  record  the  values  of  key  system  variables,  relationships  can  be  established 
by  linking  the  cells  and  then  the  variables  can  be  updated  according  to  formulas  that  define 
these  relationships.  The  analysts  can  then  conduct  “what-if  ’  scenarios  to  study  how 
changes  in  one  variable  affect  other  system  variables.  This  type  of  simulation  may  be 
appropriate  for  simple  systems,  but  it  is  very  difficult  to  use  a  spreadsheet  to  capture  how 
a  system  changes  over  time. 

When  a  system  is  too  complex  for  a  spreadsheet  simulation,  or  when  changes  over 
time  are  important,  it  is  usually  necessary  to  employ  some  type  of  simulation  software 
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such  as  ProModel,  Service  Model,  or  Power  Sim.  These  are  computer  programs 
specifically  designed  to  allow  analysts  to  model  system  dynamics  on  a  personal  computer. 
The  analyst  must  first  use  the  program  to  build  a  model  of  the  system.  This  involves 
describing  the  elements  of  the  system,  specifying  their  important  characteristics,  defining 
relationships,  and  incorporating  logic  about  how  entities  flow  through  the  system.  Once 
the  model  is  complete,  the  analyst  can  execute  it  and  have  the  computer  track  the  state  of 
key  system  variables.  Typically,  multiple  iterations  are  run,  and  the  results  allow  the 

analyst  to  statistically  determine  important  quantities  such  as  the  mean,  standard  deviation, 

- 

maximum,  and  minimum  for  "key  system  variables.  The  software  makes  it  easy  to 
incorporate  minor  changes  into  the  model,  run  the  simulation  again,  and  analyze  the  new 
results. 

There  are  cases  where  simulation  software  is  not  adequate  to  model  a  system.  This 
can  happen  when  a  system  is  very  complex,  where  unpredictable  human  reactions  are 
expected,  or  when  many  of  the  relationships  within  the  system  are  difficult  to  establish.  In 
these  cases,  it  may  be  necessary  to  simulate  the  system  by  actually  constructing  a 
simplified  version  of  the  system.  For  example,  automobile  companies  might  build  a 
prototype  of  a  vehicle  in  order  to  test  how  the  proposed  sub-systems  will  interact  An 
infantry  company  might  simulate  a  movement  to  contact  by  having  key  unit  personnel 
walk  through  the  planned  mission.  A  chemical  processing  plant  might  test  the  design  of  a 
new  system  by  creating  a  small  scale  model  of  the  equipment  involved.  Each  of  these 
examples  are  a  type  of  simulation.  They  add  a  degree  of  realism  that  is  difficult  to  obtain 
from  computer  simulations,  but  do  so  at  the  expense  of  increased  cost,  increased  time,  and 
decreased  flexibility. 

Notes: 

[1]  Webster’s  II  New  Riverside  University  Dictionary  (Boston:  Houghton  Mifflin 
Company,  1994)  761. 

[2]  Design  IDEF  Tutorial  for  Microsoft  Windows  (Cambridge:  Meta  Software 
Corporation,  1995)  2-2. 

[3]  Jerry  Banks  and  John  S.  Carlson,  n,  Discrete-Event  System  Simulation  (Englewood 
Cliffs:  Prentice  Hall  Inc,  1984) 
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[4]  Charles  Harrell  and  Kerim  Tumay,  Simulation  Made  Easy  (Norcross:  Institute  of 
Industrial  Engineers,  1995)  13. 

[5]  J.W.  Schmidt  and  R.  E.  Taylor,  Simulation  and  Analysis  of  Industrial  Systems 
(Homewood:  Irwin,  1970) 
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